Pour moi, cela ressemble à un bug, mais dans ce cas, je devrais voir un sujet à ce sujet ici. Donc, si mon forum est le seul concerné, cela doit être un problème de mon côté.
De toute façon.
Mes utilisateurs Android ne peuvent pas voir le clavier virtuel lorsqu’ils utilisent l’éditeur de texte enrichi. En passant au Markdown, tout fonctionne correctement. Les iPads et iPhones (Safari/PWA, DiscourseHub) sont bloqués en Markdown et ne peuvent pas passer à l’éditeur de texte enrichi.
Cela a commencé il y a deux jours, je crois. Mes utilisateurs ont tendance à attendre avant de me dire que quelque chose ne fonctionne pas.
Quoi d’autre… auto-hébergé, 2 conteneurs, à jour et mis à jour chaque jour, et la dernière version date de 20 minutes à l’heure où j’écris ceci, le mode sans échec ne résout rien.
Quelle est ma prochaine étape ? La console et les erreurs possibles ne sont pas une option sur les appareils mobiles.
(index):1 Access to script at 'https://cdnfoorumi.katiska.eu/assets/br/chunk-coedl1gv.digested.js' from origin 'https://foorumi.katiska.eu' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
prosemirror-editor-opfbo6zd.digested.js:1 GET https://cdnfoorumi.katiska.eu/assets/br/chunk-coedl1gv.digested.js net::ERR_FAILED 200 (OK)
d-editor.gjs:212 Uncaught (in promise) TypeError: Failed to fetch dynamically imported module: https://cdnfoorumi.katiska.eu/assets/br/prosemirror-editor-opfbo6zd.digested.js
Prosemirror est l’éditeur de texte enrichi (RTEditor). Mais je ne peux pas aider davantage que de partager le message d’erreur que je vois.
Hors sujet : Merci pour le fou rire concernant ta catégorie « Baisers et animaux » (Malheureusement, la traduction anglaise dit « chats » à la place, donc je m’en tiendrai à la version allemande )
Je ne comprends pas ce que je vois ici, mais le problème vient-il de S3 et de mes réglages là-bas ? Si oui, pourquoi est-ce arrivé récemment ? Un symptôme pourrait être que, depuis hier, je n’arrivais plus à écrire de notes sur les forums.
Mais si CORS est le problème, pourquoi seules ces ressources sont-elles affectées ?
—
Pourquoi, au nom des dieux anciens et nouveaux, l’IA a-t-elle utilisé Küsse dans ce contexte
Je ne pense pas qu’il y ait eu des récentes modifications de Discourse pour en être la cause. Cependant, S3 a un comportement étrange bien connu concernant CORS, qui peut amener les CDN à mettre en cache une version de la ressource sans l’en-tête Access-Control-Allow-Origin. Et s’il s’agit d’un problème de cache corrompu, cela pourrait expliquer pourquoi cela n’affecte que certains de vos utilisateurs (probablement en fonction de leur localisation).
Si je me souviens bien, S3 ne renvoie l’en-tête Access-Control-Allow-Origin que pour les requêtes qui envoient un en-tête Origin (c’est-à-dire celles provenant d’un navigateur web standard). Lorsque Access-Control-Allow-Origin est omis, il ne fournit pas Vary: origin dans sa réponse. Et donc : si la première requête pour une ressource donnée est envoyée depuis un contexte non-navigateur (par exemple curl, ou un robot d’indexation), le CDN peut mettre en cache la version sans l’en-tête CORS. Très agaçant !
Le paramètre DISCOURSE_CORS ne sera d’aucune utilité ici. Il ne concerne que le serveur d’application, pas S3.
Sur notre hébergement, nous contourner ce problème en configurant Cloudfront pour ajouter Access-Control-Allow-Origin: * à toutes les réponses. Cela garantit que le comportement étrange de S3 ne peut pas entraîner la mise en cache d’un résultat incorrect.
Alternativement, vous pouvez configurer Cloudfront pour inclure l’en-tête de requête Origin dans sa clé de cache, ce qui permettrait de séparer les réponses sans CORS des réponses avec CORS.
Amazon a une documentation complète sur CORS ici. J’avais ce lien dans mes notes, qui apparemment était un fil de forum sur exactement ce problème… mais il semble qu’ils l’aient supprimé
Oui, c’est vrai — je suis bien en train d’utiliser AWS CloudFront Si je me souviens bien, il faut utiliser son propre nom de domaine. Ou quelque chose comme ça.
Oui, exactement — c’est nécessaire pour un domaine personnalisé, et cela permet aussi de réduire les coûts (la sortie via Cloudfront est moins chère que la sortie directe depuis S3, si ma mémoire est bonne)
Premièrement, j’ai supprimé toutes les références S3 du fichier web_only.yml. J’ai effectué un rebuild et, par précaution, une commande rake posts:rebake. Les problèmes ont disparu, mais les images continuaient bien sûr à être servies via le CDN. J’ai réintégré S3 et le problème est réapparu.
J’ai ouvert AWS et j’ai jeté un coup d’œil aux paramètres de distribution dans CloudFront. J’y avais au moins un domaine qui datait d’au moins trois ans et dont le TLD avait changé. Je trouve étonnant que quoi que ce soit ait fonctionné. J’ai modifié les paramètres conformément aux recommandations de CloudFront et, à un certain endroit, j’ai également défini access-control-allow-origin: * (ce qui est stupide, car cela rend le CORS inutile). Cependant, d’après ma compréhension, cet en-tête était déjà servi via CloudFront.
Par précaution, j’ai de nouveau effectué un rebuild et des tests. Cela n’a pas aidé.
Comme il est possible que le cache pose problème, j’ai invalidé /assets/* et, par précaution, également /assets/br/*. Un nouveau rebuild a été effectué et le problème a été résolu.
Un autre problème a également été corrigé. Depuis l’été, je rencontre un problème Oops…, c’est-à-dire une erreur 50x après un rebuild. Lorsque j’active le mode sans échec et que je désactive les thèmes, je peux accéder à l’administration. Je dois désactiver plusieurs TC, soit plus de 20, et le forum reprend vie. Ensuite, je peux réactiver ces composants et tout fonctionne à nouveau.
Peut-on donc en conclure que tout est né des problèmes avec AWS CloudFront ?
Le problème avec Oops est assez surprenant — je ne m’attendais pas à ce que cela soit lié à Cloudfront… Mais s’il est corrigé maintenant… tant mieux !
Cela signifie simplement « cet actif est autorisé à être utilisé depuis un contexte inter-sites ». Vous ne voudriez probablement pas ce en-tête sur les réponses HTTP du forum lui-même. Mais pour les actifs statiques, qui ne nécessitent pas d’authentification et ne contiennent aucune information privée, c’est tout à fait acceptable. C’est exactement la façon dont le système CORS est censé être utilisé — pour permettre aux serveurs de contrôler sélectivement quelles réponses doivent être disponibles inter-sites.
Si vous le souhaitiez vraiment, vous pourriez définir Access-Control-Allow-Origin: my-forum.example.com. Mais vous rencontrerez alors des problèmes si vous changez un jour le domaine de votre forum.
)
)
Si je me souviens bien, il faut utiliser son propre nom de domaine. Ou quelque chose comme ça.