Ich glaube nicht, dass es kürzlich Änderungen an Discourse gab, die dies verursacht haben. S3 hat jedoch ein langjähriges seltsames Verhalten im Zusammenhang mit CORS, das dazu führen kann, dass CDNs eine Version des Assets ohne den Access-Control-Allow-Origin-Header cachen. Und wenn es sich um ein Problem mit einem fehlerhaften Cache handelt, könnte das erklären, warum nur einige deiner Benutzer betroffen sind (vermutlich basierend auf ihrem Standort).
Sofern ich mich recht erinnere: S3 liefert den Access-Control-Allow-Origin-Header nur für Anfragen, die einen Origin-Header senden (d. h. solche von einem normalen Webbrowser). Wenn Access-Control-Allow-Origin weggelassen wird, liefert S3 auch keinen Vary: origin-Header in seiner Antwort. Und so: Wenn die erste Anfrage für ein bestimmtes Asset aus einem Kontext außerhalb des Webbrowsers gesendet wird (z. B. curl oder ein Webcrawler), kann das CDN die Version ohne den CORS-Header cachen. Sehr nervig!
Die Einstellung DISCOURSE_CORS hilft hier überhaupt nicht. Sie ist nur für den Anwendungsserver relevant, nicht für S3.
Bei unserem Hosting umgehen wir dieses Problem, indem wir CloudFront so konfigurieren, dass Access-Control-Allow-Origin: * zu allen Antworten hinzugefügt wird. Das stellt sicher, dass das seltsame Verhalten von S3 nicht dazu führen kann, dass ein fehlerhaftes Ergebnis gecacht wird.
Alternativ könntest du CloudFront so konfigurieren, dass der Origin-Anfrageheader in seinen Cache-Key aufgenommen wird, wodurch die Antworten ohne CORS von den Antworten mit CORS getrennt gehalten werden.
Amazon hat eine Reihe von Dokumentationen zu CORS hier. Ich hatte diesen Link in meinen Notizen, der offenbar ein Forenthread zu genau diesem Problem war … aber es scheint, als hätten sie ihn gelöscht 