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é 