Nenhum cabeçalho 'Access-Control-Allow-Origin' presente, apesar de definir DISCOURSE_ENABLE_CORS: true

Suporte
1

Adicionei as seguintes declarações ao nosso app.yml:

  DISCOURSE_ENABLE_CORS: true
  DISCOURSE_CORS_ORIGIN: '*'

Defini temporariamente ‘*’ para eliminar variáveis durante os testes. Também tentei definir URLs explicitamente, sem sucesso.

No entanto, apesar do acima, ainda recebemos:

Blockquote

O cabeçalho ‘Access-Control-Allow-Origin’ não está presente no recurso solicitado.

Contexto: Temos um cliente iOS baseado em Unity que se integra a algumas APIs do Discourse e, para testes, usamos WebGL. Enfrentamos esse problema ao testar em nossos navegadores executando WebGL especificamente.

Também observei, em testes pelo Postman, que todas as solicitações possuem uma política de referenciamento ‘strict-origin-when-cross-origin’ nos cabeçalhos de resposta.

Qualquer ajuda é apreciada. Obrigado!

1 curtida
2

A configuração cors origins é controlada em admin > settings > security

Você só precisa de DISCOURSE_ENABLE_CORS: no seu app.yml

1 curtida
3

Eu também tentei e testei isso

image
image2576×834 140 KB

4

E para nossa configuração de site único, definir a origem no .yml ou na interface de administração deve ter o mesmo efeito, conforme: What is the purpose of Settings -> Security -> CORS origins vs similar environment setting?

1 curtida
5

Não temos certeza se o curinga é suportado aqui. Você pode tentar com um domínio real? Estamos usando as configurações de CORS em alguns sites com domínios configurados e parece funcionar bem.

1 curtida
6

Eu também configurei em um dos meus sites e funciona.

1 curtida
7

Tentei com um domínio, sem sucesso. Existe alguma maneira de confirmar se as variáveis de ambiente estão configuradas corretamente? (ou que o reinício do app configurou o CORS sem reenviar solicitações, apenas tentando pensar em formas de depurar).

Acho que esta é a parte do código que lida com as configurações de CORS, caso seja útil.

image
image1920×790 78.9 KB

1 curtida
8

image
image3392×564 147 KB

Nos logs de acesso do nginx, notei que a chamada OPTIONS retorna 404 (e precede o erro na chamada GET).

1 curtida