Isso seria uma boa resposta para mim, exceto que não consigo fazer a autenticação por cabeçalho funcionar, então estou tentando fazer isso com formulários e também estou enfrentando problemas com CSRF. Alguma solução? Estou tentando criar um novo tópico usando a API.
Precisaremos de mais informações para poder ajudar. Você pode compartilhar um trecho de código mostrando como está tentando usar a autenticação baseada em cabeçalhos?
O problema que tenho enfrentado ocorre principalmente sempre que tento fazer uma chamada com autenticação baseada em cabeçalhos: os cabeçalhos aceitos são sempre “User-Api-Key” e “User-Client-Id” em vez de “Api-Key” e “Api-Username”, o que resulta em erros de CORS. Não acredito que precise de chaves baseadas em usuário. Estou apenas tentando fazer uma solicitação simples autenticada para criar um novo tópico. Se tento usar “User-Api-Key”, recebo um erro 403.
Abaixo está um código de exemplo (Angular TypeScript), mas deve ser semelhante a outras configurações:
createNewTopic(postBody: any) {
let url = "myserver.com/posts.json";
let CATEGORY_ARTICLES = 6;
let topicContent = `
<p>Algum conteúdo
</p>
<p>Funcionou?</p>
`;
let post = {
"title": "Tdk Test 1",
"raw": topicContent,
"category": CATEGORY_ARTICLES,
"target_usernames": "tdekoekkoek",
"archetype": "",
"created_at": new Date()
}
let headers = new HttpHeaders()
.set("Accept", "application/json")
.set("User-Api-Key", DISCOURSE_API_KEY)
.set("User-Key", "system")
.set("Content-Type", "application/x-www-form-urlencoded")
let options = {headers: headers};
return this.http.post(url, post, options);
}
user-api-key e user-client-id são um método de autenticação completamente diferente. Chaves de API regulares não funcionarão com esses cabeçalhos. O que acontece quando você usa os nomes de cabeçalho corretos? (api-key e api-username)
Estou recebendo um erro CORS porque o servidor está esperando User-Api-Key. Examinei os cabeçalhos esperados na resposta OPTIONS e é isso que está escrito. Há um tópico semelhante em outro lugar neste fórum onde um usuário estava enfrentando isso ao chamar de um aplicativo JavaScript.
Ah, então você está tentando fazer essa solicitação a partir de uma aplicação JavaScript no lado do cliente? Isso não é permitido por vários motivos. Por exemplo, se você incluir uma chave de API de administrador no código-fonte do seu aplicativo JavaScript, qualquer usuário poderá obter acesso total de administrador ao seu fórum. Aqui está um tópico anterior sobre o assunto.
Sim, é isso que estou tentando fazer. Isso deveria estar documentado de forma mais clara. Essa tem sido toda a minha estratégia desde que comecei com o Discourse. Agradeço sua ajuda. Tenho lutado com isso há dias e lendo a documentação. Vou ter que repensar toda a minha abordagem, pois estou construindo atualmente uma aplicação serverless, embora eu tenha acesso a um servidor Node.js.
Isso não é uma restrição específica do Discourse - em geral, é uma má ideia incluir credenciais de administrador no código-fonte de um site.
Se você puder fazer a chamada à API do Discourse a partir do seu servidor Node.js, essa provavelmente seria a melhor solução. Se precisar que seu aplicativo seja puramente do lado do cliente, solicitar chaves de API específicas do usuário é uma opção, embora sua configuração seja muito mais complexa: User API keys specification
Francamente, acessar APIs a partir de aplicações cliente com CORS habilitado é extremamente comum e padrão. Não consigo acreditar que não exista uma maneira mais segura de fazer isso. Uma indústria inteira gira em torno de APIs hospedadas acessadas de diferentes domínios. Quanto ao acesso com API de usuário, já vi como criá-las, mas não tenho certeza sobre quais são as credenciais reais. Sempre recebo um erro 403 de permissão negada ao usar esse método.
Acho que estou em uma situação semelhante.
Um pouco sobre o caso de uso:
Eu uso o Discourse como backend e construo o frontend em VueJS. Pretendo usar apenas a REST API. Para cada usuário em nossa plataforma, criei uma chave de API de usuário e utilizo ambos os cabeçalhos (Api-Key e Api-Username) para autenticação.
Cada usuário se autentica com segurança em nossos servidores e, em seguida, recebe seu Token do Discourse para autenticação. Depois, desejamos usar esse token (no frontend VueJS) para enviar solicitações de API (criar tópicos, posts, editar, etc.).
Nada está codificado manualmente; todos os tokens são recebidos após a autenticação adequada.
O Problema:
Estou recebendo uma mensagem de erro CORS, mesmo tendo ativado a opção no app.yml e configurado na seção de Segurança das Configurações de Administrador.
O erro: O campo de cabeçalho de solicitação api-key não é permitido por Access-Control-Allow-Headers
Estou enfrentando o erro CORS pelo mesmo motivo? Por que as solicitações CORS são bloqueadas ao usar os cabeçalhos “Api-Key” e “Api-Username”? Devo estar interpretando mal o caso de uso deles.
EDIT:
Tenho uma teoria sobre meu equívoco. Quando crio uma chave de API de usuário a partir do endpoint “Generate an api_key for a user” da REST API, essa chave tem permissões administrativas? Essa chave não seria apenas uma chave de usuário para postar e comentar? Se for esse o caso, então entendo a restrição.
Por favor, me corrija se necessário.
@david o Discourse não pode simplesmente ter o servidor assinando um segredo de sessão com um HMAC, e este segredo de sessão, por sua vez, pode ser usado para assinar coisas na sessão dada? Se for roubado, então presumivelmente o cookie de sessão ou o nonce CSRF também não seriam. É um pouco como uma cadeia de certificados - você não precisa colocar a chave raiz no navegador.
Estas são apenas para a API de administração. A forma como entendi é que, para clientes JavaScript, você precisa, como mencionado acima, verificar o User API keys specification .