Depuis la semaine dernière, tous les plugins, qu’ils soient intégrés ou installés, ont cessé de fonctionner, même lorsqu’ils sont activés sur notre forum. Au début, je pensais que cela était lié au bug mentionné précédemment : FIX: Compile missing rollup plugin bundles on demand in development - #8, mais nous avons effectué plusieurs mises à jour depuis sans que rien ne résolve le problème. J’ai essayé d’activer un plugin précédemment inutilisé, celui de « Notes utilisateur » préinstallé, mais aucune option n’apparaît pour ajouter des notes aux utilisateurs. Même le gestionnaire Docker a cessé de fonctionner, ce qui oblige à exécuter toutes les mises à jour au niveau du serveur, permettant ainsi à une seule personne de les appliquer au lieu de toute l’équipe d’administration.
J’ai cherché une solution pour ce problème, mais tout ce que j’ai trouvé concerne des plugins désactivés automatiquement ou des situations similaires, rien d’aussi précis que notre cas.
Pourriez-vous, s’il vous plaît, suggérer des solutions possibles ou des pistes à explorer, car nous cherchons à éviter une restauration (rollback), même si pour l’instant cela semble être la dernière option.
Merci comme toujours à tous ici pour votre soutien continu
J’ai activé mon plugin d’ignorance CORS et les scripts se sont chargés avec succès, mais je ne vois aucune modification visible provenant des plugins. Je vous recommande d’essayer cela, et si cela fonctionne, vous devriez identifier ce qui cause l’erreur avec votre CDN.
Merci beaucoup d’avoir pris le temps de vous pencher sur ce sujet pour nous. Nous effectuerons des tests ce week-end et vous tiendrons informés dès que possible.
Je rencontre le même problème avec BunnyCDN. Tout fonctionnait correctement jusqu’à une mise à jour récente.
J’ai essayé d’ajouter .js aux en-têtes CORS sur bunny.net comme décrit ici :
Comme c’était le cas à l’époque, je ne comprends pas pourquoi ce problème est apparu lorsque j’ai effectué la mise à niveau vers 6800ad3adf3ef9c3caeb9a4d849997c7a3dc98d7 la semaine dernière.
Merci Jay, nous avons Bunny et la correction que vous avez mentionnée a résolu tous les problèmes maintenant ! Merci à vous et à tous pour l’aide et le soutien apportés à ce sujet, notre forum est de retour à la normale. Enfin, aussi normal que possible
Ravi d’apprendre que vous avez résolu le problème !
Dans le nouveau système de plugins, nous utilisons script type="module", ce qui nécessite que les en-têtes CORS appropriés soient définis. Les anciennes balises script type="text/javascript" ne nécessitent pas ces en-têtes.
Nous avons progressivement migré différents systèmes vers type="module" au cours des dernières années. Les thèmes l’utilisaient déjà, tout comme highlightjs (qui était mentionné dans l’autre sujet). Le chargement des polices depuis le CDN impose également une exigence CORS.
Il y avait donc probablement d’autres éléments subtilement défectueux, même avant les récentes modifications apportées au système de plugins. Maintenant que vous avez configuré les paramètres CORS, tout devrait fonctionner à nouveau
Juste un petit avertissement pour les utilisateurs : si vous utilisez Azure Classic CDN, ce problème a commencé à se produire. J’essaie une correction côté CDN, mais il se peut que je doive migrer vers Front Door plutôt que vers le CDN classique.
Y a-t-il un endroit où trouver des instructions ou des conseils concernant ces récentes modifications liées à CORS pour ceux d’entre nous qui utilisent Cloudflare ?
@pfaffman@TomoftheFog@tanya_byrne@denvergeeks pourriez-vous s’il vous plaît confirmer comment vos ressources sont configurées ? Avez-vous simplement un CDN + le serveur d’application ? Ou stockez-vous également les ressources sur S3 ou un stockage compatible S3 ?
Si vous utilisez un stockage S3 ou compatible S3, alors malheureusement, la seule méthode fiable consiste à ajouter une configuration spécifique au CDN. J’avais supposé que ce sujet concernait les ressources S3, mais maintenant, je ne suis plus aussi sûr.
Pour les personnes utilisant un CDN simple face au serveur d’application, aucune configuration supplémentaire ne devrait avoir été nécessaire. Cela devrait « fonctionner tout seul », exactement de la même manière que les bundles theme-javascripts et hightlightjs. Mais il semble que nous ayons effectivement manqué l’en-tête dans notre configuration NGINX par défaut. Désolé pour cela !
Cela devrait permettre de faire fonctionner les choses à nouveau :
Une fois cela fusionné, une commande ./launcher rebuild app sera requise pour que cela prenne effet. Les modifications de configuration NGINX ne sont pas appliquées lors des mises à jour de l’interface utilisateur.
Désolé pour la perturbation ! Nous aurions dû effectuer des tests plus approfondis avec différentes configurations de CDN. Veuillez nous faire savoir si vous rencontrez toujours des problèmes après une reconstruction.
Tous les sites que je connais et qui présentent ce problème sont hébergés sur S3. Certains CDNs avaient déjà du JS dans la liste, d’autres non. Je ne sais pas pourquoi ; peut-être que les paramètres par défaut ont changé au fil des ans ?
J’ai eu du mal à faire fonctionner les paramètres CORS dans Cloudflare R2 avec un domaine personnalisé. J’ai fini par y parvenir en forçant l’ajout du bon en-tête pour mon domaine CDN via une règle de transformation d’en-tête. Au cas où cela aiderait quelqu’un d’autre.
Nous avons également découvert un autre problème depuis la survenue de ce problème : certains utilisateurs ne parviennent pas à voir les images d’avatar lorsqu’ils utilisent le bouton Markdown « Texte préformaté ». Il tente de charger highlight-js et génère une erreur indiquant que l’échec CORS s’est produit :
Je suppose que f.insertcred.it est votre CDN S3 ? HighlightJS devrait être chargé depuis le « CDN de l’application », et non le CDN S3, ce qui rend ce problème surprenant. À ma connaissance, rien lié à highlightjs n’a changé au cours des derniers mois.
Avez-vous un CDN d’application ? Ou seulement S3 + CDN S3 ?
J’ai reçu une mise à jour de l’administrateur principal du forum :
À ma connaissance, nous n’avons pas d’application CDN. Nous n’avons pas décommenté DISCOURSE_CDN_URL dans app.yml.
Nous utilisons uniquement les variables S3 comme DISCOURSE_S3_ENDPOINT et DISCOURSE_S3_CDN_URL, etc.
Voici notre fichier app.yml avec les informations sensibles supprimées
## Ceci est le modèle de conteneur Docker Discourse tout-en-un, autonome
##
## Après avoir apporté des modifications à ce fichier, vous DEVEZ reconstruire
## /var/discourse/launcher rebuild app
##
## SOYEZ *TRÈS* PRUDENT EN ÉDITANT !
## LES FICHIERS YAML SONT EXTRÊMEMENT SENSIBLES AUX ERREURS D'ESPACE OU D'ALIGNEMENT !
## visitez http://www.yamllint.com/ pour valider ce fichier si nécessaire
templates:
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/web.template.yml"
## Décommentez la ligne suivante pour activer l'écouteur IPv6
#- "templates/web.ipv6.template.yml"
- "templates/web.ratelimited.template.yml"
## Décommentez ces deux lignes si vous souhaitez ajouter Lets Encrypt (https)
- "templates/web.ssl.template.yml"
- "templates/web.letsencrypt.ssl.template.yml"
## Quels ports TCP/IP ce conteneur doit-il exposer ?
## Si vous souhaitez que Discourse partage un port avec un autre serveur web comme Apache ou nginx,
## consultez https://meta.discourse.org/t/17247 pour plus de détails
expose:
- "80:80" # http
- "443:443" # https
params:
db_default_text_search_config: "pg_catalog.english"
## Définissez db_shared_buffers à un maximum de 25 % de la mémoire totale.
## Sera défini automatiquement par bootstrap en fonction de la RAM détectée, ou vous pouvez le remplacer
db_shared_buffers: "256MB"
## peut améliorer les performances de tri, mais ajoute une utilisation de la mémoire par connexion
#db_work_mem: "40MB"
## Quelle révision Git ce conteneur doit-il utiliser ? (par défaut : tests-passed)
#version: tests-passed
## Taille maximale de téléversement (par défaut : 10m)
upload_size: 20m
env:
LC_ALL: en_US.UTF-8
LANG: en_US.UTF-8
LANGUAGE: en_US.UTF-8
# DISCOURSE_DEFAULT_LOCALE: en
## Combien de requêtes web simultanées sont prises en charge ? Dépend de la mémoire et des cœurs CPU.
## Sera défini automatiquement par bootstrap en fonction des CPU détectés, ou vous pouvez le remplacer
UNICORN_WORKERS: 4
## TODO : Le nom de domaine auquel cette instance Discourse répondra
## Requis. Discourse ne fonctionnera pas avec une adresse IP brute.
DISCOURSE_HOSTNAME: forums.insertcredit.com
## Décommentez si vous souhaitez que le conteneur soit démarré avec le même
## nom d'hôte (-h option) que spécifié ci-dessus (par défaut "$hostname-$config")
#DOCKER_USE_HOSTNAME: true
## TODO : Liste d'e-mails séparés par des virgules qui seront administrateurs et développeurs
## lors de l'inscription initiale, exemple 'user1@example.com,user2@example.com'
DISCOURSE_DEVELOPER_EMAILS: 'EMAIL'
## TODO : Le serveur de messagerie SMTP utilisé pour valider les nouveaux comptes et envoyer des notifications
# L'adresse SMTP, le nom d'utilisateur et le mot de passe sont requis
# ATTENTION, le caractère '#' dans le mot de passe SMTP peut causer des problèmes !
DISCOURSE_SMTP_ADDRESS: smtp.mailgun.org
DISCOURSE_SMTP_PORT: 587
DISCOURSE_SMTP_USER_NAME: USERNAME
DISCOURSE_SMTP_PASSWORD: "PASSWORD"
DISCOURSE_SMTP_ENABLE_START_TLS: true # (optionnel, par défaut true)
DISCOURSE_SMTP_DOMAIN: forums.insertcredit.com
DISCOURSE_NOTIFICATION_EMAIL: noreply@forum.insertcred.it
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: nyc3
DISCOURSE_S3_ENDPOINT: https://nyc3.digitaloceanspaces.com
DISCOURSE_S3_ACCESS_KEY_ID: KEY_ID
DISCOURSE_S3_SECRET_ACCESS_KEY: ACCESS_KEY_VALYE
DISCOURSE_S3_CDN_URL: https://f.insertcred.it
DISCOURSE_S3_BUCKET: insertcredit-forum
DISCOURSE_S3_BACKUP_BUCKET: insertcredit-forum-backup
DISCOURSE_BACKUP_LOCATION: s3
DISCOURSE_S3_INSTALL_CORS_RULE: false
DISCOURSE_CAN_PERMANENTLY_DELETE: true
## Si vous avez ajouté le modèle Lets Encrypt, décommentez ci-dessous pour obtenir un certificat SSL gratuit
LETSENCRYPT_ACCOUNT_EMAIL: EMAIL
## L'adresse CDN http ou https pour cette instance Discourse (configurée pour récupérer)
## consultez https://meta.discourse.org/t/14857 pour plus de détails
#DISCOURSE_CDN_URL: https://discourse-cdn.example.com
## La clé d'adresse IP Maxmind pour la recherche d'adresses IP
## consultez https://meta.discourse.org/t/-/137387/23 pour plus de détails
#DISCOURSE_MAXMIND_LICENSE_KEY: 1234567890123456
## Le conteneur Docker est sans état ; toutes les données sont stockées dans /shared
volumes:
- volume:
host: /var/discourse/shared/standalone
guest: /shared
- volume:
host: /var/discourse/shared/standalone/log/var-log
guest: /var/log
## Les plugins vont ici
## consultez https://meta.discourse.org/t/19157 pour plus de détails
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone https://github.com/discourse/docker_manager.git
- git clone https://github.com/discourse/discourse-bbcode-color.git
- git clone https://github.com/discourse/discourse-signatures.git
- git clone https://github.com/discourse/discourse-chart.git
after_assets_precompile:
- exec:
cd: $home
cmd:
- sudo -E -u discourse bundle exec rake s3:upload_assets
- sudo -E -u discourse bundle exec rake s3:expire_missing_assets
## Toutes les commandes personnalisées à exécuter après la construction
run:
- exec: echo "Début des commandes personnalisées"
## Si vous souhaitez définir l'adresse e-mail 'From' pour votre première inscription, décommentez et modifiez :
## Après avoir reçu le premier e-mail d'inscription, re-commentez la ligne. Elle ne doit être exécutée qu'une seule fois.
#- exec: rails r "SiteSetting.notification_email='info@unconfigured.discourse.org'"
- exec: echo "Fin des commandes personnalisées"
J’espère que cela vous sera d’une certaine aide concernant la demande. Une chose à noter est que nous n’avons reçu aucun rapport concernant les problèmes de disparition des avatars que nous avons eus il y a quelques jours. À ma connaissance, rien n’a été modifié, donc nous ne savons pas si le problème concernait juste un petit groupe d’utilisateurs et que, depuis que le problème précédent a été résolu, il s’est résolu de lui-même au fil du temps.
