Nessun header 'Access-Control-Allow-Origin' presente nonostante l'impostazione di DISCOURSE_ENABLE_CORS: true

Ho aggiunto le seguenti righe nel nostro app.yml

  DISCOURSE_ENABLE_CORS: true
  DISCOURSE_CORS_ORIGIN: '*'

Ho impostato temporaneamente ‘*’ per eliminare le variabili durante i test. Ho anche provato a impostare esplicitamente gli URL, ma senza successo.

Tuttavia, nonostante quanto sopra, otteniamo ancora

Blockquote

L’intestazione ‘Access-Control-Allow-Origin’ non è presente sulla risorsa richiesta.

Contesto: Abbiamo un client iOS basato su Unity che interagisce con alcune API di Discourse e, per i test, utilizziamo WebGL. Incontriamo questo problema quando testiamo sui browser che eseguono WebGL in particolare.

Sto anche notando dai test con Postman che tutte le richieste hanno una ‘strict-origin-when-cross-origin’ Referrer-Policy nelle intestazioni di risposta.

Qualsiasi aiuto è apprezzato. Grazie!

1 Mi Piace

L’impostazione cors origins è controllata in admin > settings > security

È sufficiente avere DISCOURSE_ENABLE_CORS: nel file app.yml

1 Mi Piace

Ho provato e testato anche questo

E per la nostra configurazione con singolo sito, impostare l’origine nel file .yml rispetto all’interfaccia di amministrazione dovrebbe avere lo stesso effetto, come descritto qui: What is the purpose of Settings -> Security -> CORS origins vs similar environment setting?

1 Mi Piace

Non sono sicuro che qui supportiamo il wildcard. Puoi provarlo con un dominio reale? Stiamo utilizzando le impostazioni CORS su alcuni siti con domini configurati e sembra funzionare correttamente.

1 Mi Piace

L’ho impostato anche su uno dei miei siti e funziona.

1 Mi Piace

Ho provato con un dominio, ma senza successo. C’è un modo per confermare che le variabili d’ambiente siano impostate correttamente? (O che il riavvio dell’app abbia configurato il CORS senza inviare nuovamente le richieste, sto solo cercando di capire come fare debug).

Penso che questa sia la parte del codice che gestisce le impostazioni del CORS, nel caso possa essere utile.

1 Mi Piace

Nei log di accesso di nginx, noto che la chiamata OPTIONS restituisce un 404 (e precede l’errore nella chiamata GET)

1 Mi Piace