Acho que o padrão de allowed_user_api_auth_redirects, “discourse://auth_redirect”, é bastante restritivo, especialmente porque “discourse” não parece ser um esquema de URI válido.
Por favor, explique o raciocínio por trás desse padrão. Obrigado.
Estou enfrentando o mesmo problema. Se eu iniciar a API a partir de um aplicativo JS, automaticamente os cabeçalhos permitidos são: User-Api-Key e User-Api-Client-Id, mesmo sem eu precisar de chaves de API de usuário. Tudo o que quero é uma chave de API simples, mas não consigo fazer nada funcionar. Se tentar passar Api-Key nos cabeçalhos, recebo um erro CORS, pois ele espera User-Api-Key. Mas quando tento usar User-Api-Key, recebo erros 403. Estou preso. Acredito que esse seja o uso básico das APIs. Não estou tentando fazer nada fora do comum. Estou apenas tentando criar uma nova postagem de tópico.
2 curtidas
Esse é o esquema de URI personalizado utilizado pelo aplicativo DiscourseHub para iOS e Android.
6 curtidas
Tenho uma dúvida sobre os “tokens de leitura” e “tokens de escrita”. Esse comentário aqui é de 2016, então isso já pode ter sido alterado? Ou os padrões ainda são apenas “tokens de leitura”?
Contexto: Sou um dos desenvolvedores por trás de um sistema de mídia social distribuído. Já temos conectores para sistemas não federados. A ideia é criar também um complemento para o Discourse. Mas, como a maioria dos sistemas provavelmente não permitirá que os usuários gerem tokens que permitam postagens, tentaremos outro caminho. Já temos um conector de e-mail. Então, usaremos simplesmente a função de lista de discussão do Discourse e tentaremos aprimorar o conteúdo retornado, postando via SMTP.
Você pode escrever tokens se solicitar o escopo de antemão
3 curtidas
Claro, isso sempre é possível. Mas tenho a sensação de que isso seria um pesadelo para o suporte. Nosso software possui algumas centenas de instalações, com (no total) mais de 10 mil usuários. Quando virem que há um complemento que se conecta ao Discourse, muitos certamente vão querer usá-lo. E, como provavelmente não funcionará imediatamente, isso gerará perguntas e trabalho de suporte da nossa parte. Além disso, isso gerará trabalho para os administradores das várias instalações do Discourse. E é muito provável que nem todos permitam isso — o que causará frustração.
Portanto, talvez eu comece focando na integração dos e-mails do modo de lista de e-mails. Ou é possível combinar essas duas coisas? Ou seja: leitura das publicações via API, mas postagem via SMTP?
Olá… não sei como gerar a public_key… devo usar um gerador RSA para obter a chave pública/privada?
Se sim, já utilizei alguns geradores RSA online, mas estou recebendo este erro:
OpenSSL::PKey::RSAError (Neither PUB key nor PRIV key: nested asn1 error) /var/www/discourse/app/controllers/user_api_keys_controller.rb:189:in `initialize'
Além disso, gostaria de perguntar a vocês se isso se adequa ao meu caso de uso:
Tenho um aplicativo e quero basicamente autenticar o usuário e obter o nome de usuário. O fluxo de geração de chave de API é o mais simples para validar o login do usuário no meu aplicativo? Se possível, gostaria de evitar o SSO, pois parece mais complicado.
Estou no mesmo barco, embora esteja apenas tentando usar User-Api-Key (e não Api-Key) para criar uma postagem de tópico e esteja recebendo uma negação de CSRF da biblioteca actionpack.
A menos que o servidor Discourse tenha desativado a verificação de CSRF, publicar a partir de um aplicativo de desktop de terceiros parece difícil. Não vou emular um navegador.
@sam, qual é a sua opinião sobre permitir que chaves de API de usuário que possuem apenas o escopo read sejam passadas via parâmetros de URL em solicitações GET?
O caso de uso é permitir integrações como assinar seu Melhorar Favoritos com Lembretes no Google Calendar usando chaves de API de usuário.
5 curtidas
Que tal criar um novo escopo específico, com um terceiro parâmetro para indicar “parâmetro get permitido”? Dessa forma, as pessoas não poderão usá-lo indevidamente para outras finalidades (por exemplo, contornar o CORS e solicitar a API do Discourse de outro site).
SCOPES = {
read: [:get],
write: [:get, :post, :patch, :put, :delete],
message_bus: [[:post, 'message_bus']],
push: nil,
one_time_password: nil,
notifications: [[:post, 'message_bus'], [:get, 'notifications#index'], [:put, 'notifications#mark_read']],
session_info: [
[:get, 'session#current'],
[:get, 'users#topic_tracking_state'],
[:get, 'list#unread'],
[:get, 'list#new'],
[:get, 'list#latest']
],
+ calendar: [ [:get, 'users#bookmarks_cal', true ] ],
}
(Ao lado: por que estamos usando arrays aninhados aqui…)
10 curtidas
Gosto de que a chave da API seja explicitamente sinalizada como “permitida em GET” no nível do usuário.
No geral, a opção poderia estar aberta para qualquer solicitação GET. A regra que prefiro, ao operar nesse modo, é:
- A chave da API do usuário está 100% restrita a uma única ação de controlador GET específica.
- A chave da API do usuário é sinalizada como permitida nos parâmetros de consulta GET.
Isso limita o impacto de qualquer vazamento aqui por meio de um proxy, pois a chave nunca será reutilizada.
Acho que {get: 'list#new'}, {get: 'list#latest'} também funcionaria.
7 curtidas
Estou super interessado em chaves de API de usuário do tipo get param only. Minha pergunta é: vocês estão planejando permitir que as pessoas gerem essas chaves por meio da interface?
Provavelmente, talvez atrás de uma configuração do site ou com um plugin. Planeja-se normalizar um pouco o conjunto de recursos para que as chaves de API de administrador também suportem escopos.
4 curtidas
Olá… Você consegue resolver esse problema? Estou com o mesmo problema e não consigo corrigi-lo. Tentei passar diferentes tipos de chaves, mas nada funcionou. Qualquer ajuda seria muito apreciada.
Existem bibliotecas para isso? Caso contrário, há um exemplo de implementação? Estou tentando usar PHP para identificar a conta do usuário do Discourse em uma parte separada do site. Isso parece um fluxo OAuth modificado, mas estou um pouco confuso sobre como implementá-lo.
Especificamente, não tenho certeza de como fazer toda a geração de chaves pública/privada.
Existe uma maneira de usar apenas OAuth 2 com o Discourse como provedor OAuth?
2 curtidas
Você conseguiu fazer isso usando a User-Api-Key? Eu também estou recebendo Você não tem permissão para visualizar o recurso solicitado.
1 curtida
Descobri o que fiz de errado: o payload retornado não é a própria chave da UserAPI, mas uma string JSON criptografada que precisaria ser descriptografada com a chave privada do par de chaves pública/privada.
2 curtidas
EDIT: Consegui fazer a maior parte funcionar e fornecerei uma descrição assim que estiver totalmente funcional.
Como o cliente obtém o par de chaves privada/pública e o ID?
Você consegue fornecer código para obter a chave da API do usuário com um aplicativo JavaScript? (Um aplicativo JavaScript tentando permitir que um usuário faça chamadas de API para um fórum Discourse).
Estou recebendo erros 403. Ou um erro dizendo: Desculpe, não é possível emitir chaves de API de usuário; este recurso pode estar desativado pelo administrador do site (embora meu site tenha marcado: Permitir geração de chaves de API de usuário).
Acho que o problema pode ser como gerar o par de chaves privada/pública (como isso é feito?) e, em seguida, lidar com o redirecionamento.
Qualquer código será muito apreciado.
Consegui fazer isso funcionar, após alguns testes e ajustes.
Aqui estão as etapas básicas que sigo quando: tenho um aplicativo separado que desenvolvi e quero que os usuários possam usá-lo para fazer chamadas de API a um site do Discourse.
Para isso, preciso gerar um token de API por usuário para fazer chamadas em nome de cada usuário específico (pelo menos em um ambiente Node.js/JavaScript).
Observe que, para a parte de JavaScript, encontrei o código fornecido por @KengoTODA aqui: discourse-api-key-generator/src/index.ts at main · KengoTODA/discourse-api-key-generator · GitHub, que foi muito útil.
Aqui estão as etapas que segui:
Primeiro: Gere um par de chaves pública e privada.
Isso é algo que seu aplicativo precisa gerar: uma chave pública e uma chave privada. O gist do GitHub fornece um método para fazer isso.
Segundo: Tenha uma URL de redirecionamento.
Esta é a URL para a qual o Discourse irá redirecionar, fornecendo o token de API final no payload. Se você tiver um aplicativo de desktop (ou seja, sem uma URL de navegador), a URL de redirecionamento será baseada em um protocolo personalizado que você configurou, que abre o aplicativo quando a URL de redirecionamento é inserida no navegador.
Observe que a URL de redirecionamento precisa estar na lista de permissões nas configurações do site do Discourse alvo.
O site do Discourse também provavelmente precisa ter a configuração do site marcada para “Permitir chaves de API do usuário”. Consulte a postagem original sobre este tópico para “Configurações do Site”.
Terceiro: Envie a chamada de solicitação de API para a URL de solicitação do Discourse.
Então, seu aplicativo enviará uma chamada para uma URL que segue este formato:
https://[seu site alvo do Discourse .com]/user-api-key-new"
e adicionando como parâmetros:
- o nome do seu aplicativo
- seu “client_id” (consegui usar hostname(), de
const {hostname} = require('os')para um aplicativo de desktop, assim como no gist do GitHub mencionado acima) - escopos (estes são os escopos que você deseja que o usuário possa realizar por meio da API, como “write”, “read”, etc.)
- sua chave pública (da etapa 1 acima)
- sua URL de redirecionamento (da etapa 2 acima)
- nonce (este é um valor que você pode escolher—usar apenas ‘1’ parece funcionar)
Quarto: O usuário autoriza seu aplicativo na página do site do Discourse aberta pela URL de solicitação.
Quando você envia a URL de solicitação com sucesso, ela abre uma página no site do Discourse informando ao usuário que seu aplicativo deseja acessar o site.
Nessa página, há um botão para o usuário permitir isso. Quando o usuário clica nesse botão, o site do Discourse redireciona para a URL de redirecionamento que você forneceu e anexa como parâmetro um ?payload=[A CHAVE DE API]. A CHAVE DE API aqui é a chave que você precisa decodificar em seu aplicativo.
Quinto: Seu aplicativo captura o valor da URL de redirecionamento (com o valor do payload) e você decodifica a CHAVE DE API.
Você está quase lá. Seu aplicativo precisa analisar a URL de redirecionamento para a qual o Discourse foi e obter a Chave de API contida no payload.
Depois de obter essa Chave de API, você precisa fazer duas coisas:
- Obter a chave real, não a versão codificada em URL: se você estiver obtendo um parâmetro de uma URL, ela geralmente está codificada em URL (adicionando % aqui e ali, etc.). Você precisa limpá-la. Em JavaScript, encontrei que
decodeURIComponentfunciona para isso. - Depois de obter a CHAVE DE API limpa retornada pelo Discourse, você precisa decodificá-la. Para isso, você pode usar a decodificação em JavaScript com chaves privadas. Basicamente, você usa sua chave privada (gerada na primeira etapa acima) para decodificar a CHAVE DE API limpa. Há algum exemplo de JavaScript no gist do GitHub que referenciei acima: discourse-api-key-generator/src/index.ts at main · KengoTODA/discourse-api-key-generator · GitHub
Depois de executar seu código de decodificação, você tem o próprio token, que agora pode usar para fazer chamadas de API autenticadas em nome do usuário.
Sexto: Use o token (ou seja, a Chave de API final, limpa e decodificada) para fazer chamadas de API em nome do usuário.
Com esse token, parece que você não precisa inserir o nome de usuário na chamada de API. Acredito que o seguinte cabeçalho seja suficiente quando incluído em suas chamadas GET, POST, PUT, etc.:
headers: {
"User-Api-Key": [o token]
}
E com isso, você espera ter um método de autenticação por usuário funcionando para interagir com o Discourse.
7 curtidas
Quais são as implicações de segurança de adicionar itens a allowed_user_api_auth_redirects? Tenho alguém pedindo para adicionar uma string para dar suporte à integração com o NextCloud.
1 curtida