I am having an issue with embedding discourse in our intranet site.
The API documentation states the discourse request requires the headers “API-Key” and “Api-Username” to authenticate and gain access to the feed. However the Pre-flight check says that “User-API-Key”, “User-Api-Client-Id” are the allowed values.
When called not through a browser this work as expected. But when calling through the browser the server is claiming it requires “User-API-Key”, “User-Api-Client-Id”.
I checked basic connection worked with PostMan this behaves as per the discourse docs
If we pass the Headers from the Docs the browser blocks the request due to Pre-flight check and gets a Access-Control-Allow-Headers CORS error.
If we pass the headers the server will accept we get a “not authorised error” because the application expects differently named values.
I have tried adding headers to the docker config but it doesn’t seem to apply. The CORS enabled and origin of ‘*’ is in the config.
We have two different API authentication systems, which can be confusing.
These are for the ‘admin API’, which is described on docs.discourse.org. This is not designed to be used from javascript clients.
These are from the “User API” specification, which can be used from a javascript client (and therefore supports CORS). There are more details about this here: User API keys specification
@david Estou usando SSO e quero fazer o logout do usuário no Discourse quando ele fizer logout do aplicativo. Atualmente, estou usando a ‘API de administrador’ para buscar o ID do usuário via /users/by-external/${id}.json, mas estou recebendo erros de CORS. Não quero habilitar a ‘API de usuário’ para todos os usuários apenas para esse processo de logout. O que você sugere?
O que está fazendo a solicitação à API de administrador? JavaScript na sua aplicação cliente?
Você não deve incluir uma API de administrador em um cliente JavaScript, pois isso significa que qualquer pessoa que use o cliente poderá obter acesso de administrador ao seu site.
Sim, é JavaScript no meu aplicativo. Entendo. Então, qual é a alternativa? Posso criar uma ‘API de usuário’ para um único usuário e usá-la para fazer a chamada para todos os usuários?
Se você usar a API de usuário, deve fazê-lo por usuário. Não compartilhe as chaves.
No entanto, o mais comum aqui seria lidar com isso no lado do servidor do seu aplicativo. Seu servidor pode enviar uma solicitação usando chaves de API de administrador sem problemas de CORS e com menos preocupações de segurança (desde que seja implementado com segurança).
Oi @david, tentei implementar uma solução de backend, mas ao chamar https://example.com/users/by-external/{EXTERNAL_USER_ID}.json?api_key={DISCOURSE_API_KEY}&api_username=system, a resposta que recebo é o HTML da página de login (acho que está redirecionando para lá). Tenho a opção “login obrigatório” ativada e, quando a desativo, recebo a resposta JSON correta. Quero manter essa configuração ativada — alguma ideia do que está acontecendo?
