No está presente la cabecera 'Access-Control-Allow-Origin' a pesar de establecer DISCOURSE_ENABLE_CORS: true

Añadí las siguientes declaraciones en nuestro app.yml:

  DISCOURSE_ENABLE_CORS: true
  DISCOURSE_CORS_ORIGIN: '*'

Establecí temporalmente ‘*’ para eliminar variables durante las pruebas. También intenté establecer las URL explícitamente, pero sin éxito.

Sin embargo, a pesar de lo anterior, aún obtenemos:

Blockquote

No hay un encabezado ‘Access-Control-Allow-Origin’ presente en el recurso solicitado.

Contexto: Tenemos un cliente iOS basado en Unity que se conecta a algunas APIs de Discourse y, para las pruebas, usamos WebGL. Nos encontramos con este problema al probar en nuestros navegadores que ejecutan WebGL específicamente.

También observo en las pruebas de Postman que todas las solicitudes tienen una política de referencia ‘strict-origin-when-cross-origin’ en los encabezados de respuesta.

Agradecería cualquier ayuda. ¡Gracias!

1 me gusta

La configuración cors origins se controla en admin > settings > security

Solo necesitas DISCOURSE_ENABLE_CORS: en tu archivo app.yml

1 me gusta

También lo intenté y lo probé

Y para nuestra configuración de sitio único, establecer el origen en .yml frente a la interfaz de administración debería tener el mismo efecto según: What is the purpose of Settings -> Security -> CORS origins vs similar environment setting?

1 me gusta

No estoy seguro de que admitamos el comodín aquí. ¿Puede probarlo con un dominio real? Estamos utilizando la configuración de CORS en varios sitios con dominios configurados y parece funcionar correctamente.

1 me gusta

también lo tengo configurado en uno de mis sitios y funciona

1 me gusta

Lo intenté con un dominio, sin éxito. ¿Hay alguna forma de confirmar que las variables de entorno están configuradas correctamente? (o que el reinicio de la aplicación configuró el CORS sin volver a enviar solicitudes, solo estoy tratando de pensar en formas de depurar).

Creo que esta es la parte del código que maneja la configuración del CORS, por si acaso es útil.

1 me gusta

En los registros de acceso de nginx, noto que la llamada OPTIONS devuelve un 404 (y precede al error en la llamada GET).

1 me gusta