Estamos usando o Discourse como ferramenta de colaboração e temos outro aplicativo para buscar documentos. Gostaríamos de integrar comentários sobre documentos ao Discourse. Ambos utilizam um provedor externo de SSO/OAuth dentro de nossa infraestrutura.
Estamos usando a Chave de API do Usuário para conectar os dois aplicativos, permitindo que eles se comuniquem. Funciona bem, mas precisamos clicar no formulário “Autorizar acesso ao aplicativo”, que gostaríamos de evitar, já que estamos em um ambiente confiável respaldado pelo OAuth.
Existe alguma maneira de evitar essa etapa de “autorização” ou contorná-la e ir diretamente para a criação da Chave de API do Usuário, de modo que essa página não seja exibida e os usuários não precisem realizar essa etapa extra? Existe algum parâmetro que possamos fornecer na solicitação para que essa etapa seja ignorada?
Tentamos chamar UserApiKeysController.create primeiro (em vez de UserApiKeysController.new), mas recebemos um erro de CSRF. Então, tentamos ignorar a verificação do token assim:
class UserApiKeysController < ApplicationController
skip_before_action :verify_authenticity_token
Posso afirmar com certeza que essa não é a maneira correta de proceder. Você já está usando um plugin ou está interagindo apenas via HTTP?
Se você está usando um plugin, na maioria dos casos, não deve interagir com instâncias de app/controllers/.
Se você está interagindo via HTTP e usando comunicação de servidor para servidor, seria mais adequado utilizar uma chave de API criada por um administrador.
A API de Usuário destina-se à comunicação de cliente para servidor, onde não há como garantir a integridade do código no lado do cliente.
Sim, estamos planejando desenvolver um plugin para o Discourse e nossa aplicação JS interagirá apenas por meio de solicitações HTTP.
Gostaríamos de evitar ter que desenvolver comunicação entre servidores (por exemplo, usando uma chave de API de administrador) para minimizar o acoplamento entre os componentes.
Entendo que, idealmente, não devemos mexer nos controladores do Discourse e, ao mesmo tempo, há muitos métodos que parecem ser projetados para serem sobrescritos (padrão de método template e outros pontos de extensão), e pelo que vimos até agora, muitos plugins fazem isso.
Se você estiver criando um plugin, deve desenvolver novas rotas em um controlador montado no plugin que executem diretamente as tarefas necessárias. Todas essas rotas podem compartilhar um before_action que define os cabeçalhos de resposta Access-Control-Allow-{Origin, Headers, Credentials} (espelhe o cabeçalho de solicitação Origin se ele estiver na lista de domínios em que seu aplicativo deve estar rodando).
Dessa forma, seu código JS pode simplesmente invocar fetch(..., { credentials: "include", ...}) sem nenhuma chave de API.
Obrigado, @riking. Isso funciona bem quando temos uma sessão aberta no Discourse no navegador.
Conseguimos iniciar uma nova sessão manualmente apenas chamando http://discourse_site/login, já que temos SiteSetting.enable_local_logins = false e apenas um mecanismo de autenticação com OAuth. O navegador segue os redirecionamentos em nosso provedor OAuth e depois redireciona para o Discourse. Era isso que acontecia internamente ao chamar /user-api-key/new.
Como poderíamos iniciar uma nova sessão no Discourse programaticamente a partir do aplicativo, caso não haja nenhuma?
talvez