Kein 'Access-Control-Allow-Origin'-Header vorhanden, obwohl DISCOURSE_ENABLE_CORS: true gesetzt ist

Unterstützung
1

Ich habe folgende Anweisungen in unsere app.yml hinzugefügt:

  DISCOURSE_ENABLE_CORS: true
  DISCOURSE_CORS_ORIGIN: '*'

Ich habe ‘*’ vorübergehend gesetzt, um beim Testen Variablen auszuschließen. Ich habe auch versucht, URLs explizit einzustellen, aber das brachte nichts.

Trotzdem erhalten wir weiterhin:

Blockquote

Die angeforderte Ressource enthält keinen Header „Access-Control-Allow-Origin".

Kontext: Wir haben einen Unity-basierten iOS-Client, der mit einigen Discourse-APIs interagiert, und für Tests verwenden wir WebGL. Wir stoßen auf dieses Problem, wenn wir Tests in Browsern durchführen, die speziell WebGL ausführen.

Ich stelle zudem fest, dass bei Postman-Tests alle Antworten einen Referrer-Policy-Wert „strict-origin-when-cross-origin" in den Antwort-Headern enthalten.

Jede Hilfe wird geschätzt. Vielen Dank!

1 „Gefällt mir“
2

Die Einstellung cors origins wird unter Admin > Einstellungen > Sicherheit gesteuert.

Sie benötigen nur DISCOURSE_ENABLE_CORS: in Ihrer app.yml.

1 „Gefällt mir“
3

Ich habe das ebenfalls versucht und getestet

image
image2576×834 140 KB

4

Und für unsere Single-Site-Konfiguration sollte das Festlegen des Ursprungs in der .yml-Datei dieselbe Wirkung haben wie über die Admin-Oberfläche, siehe: What is the purpose of Settings -> Security -> CORS origins vs similar environment setting?

1 „Gefällt mir“
5

Ich bin mir nicht sicher, ob wir hier den Wildcard-Einsatz unterstützen. Könntest du es mit einer echten Domain ausprobieren? Wir nutzen die CORS-Einstellungen auf einigen Seiten mit konfigurierten Domains, und es scheint gut zu funktionieren.

1 „Gefällt mir“
6

Ich habe es auch auf einer meiner Seiten eingerichtet, und es funktioniert.

1 „Gefällt mir“
7

Ich habe es mit einer Domain versucht, aber ohne Erfolg. Gibt es eine Möglichkeit zu überprüfen, ob die Umgebungsvariablen korrekt gesetzt sind? (Oder ob der Neustart der App die CORS-Einstellungen konfiguriert hat, ohne dass Anfragen erneut gesendet wurden – ich versuche nur, Ideen für das Debugging zu finden.)

Ich denke, dies ist der Teil des Codes, der die CORS-Einstellungen verarbeitet, falls das hilfreich sein sollte.

image
image1920×790 78.9 KB

1 „Gefällt mir“
8

image
image3392×564 147 KB

In den nginx-Zugriffsprotokollen stelle ich fest, dass der OPTIONS-Aufruf einen 404-Statuscode zurückgibt (und dem Fehler beim GET-Aufruf vorausgeht).

1 „Gefällt mir“