Olá, gostaria de perguntar sobre user_api_keys. Atualmente, estou trabalhando na integração do nosso aplicativo para usar as user_api_keys do Discourse para autorização. Minha pergunta é: existe alguma maneira de recuperar user_api_keys usando a API?
No momento, após fazer login via /session.json e verificar o perfil do usuário atual usando /users/:username.json, podemos ver se o usuário tem user_api_keys ou não, mas isso não retorna os valores reais:
O motivo pelo qual quero obter o valor de user_api_keys é para evitar exigir que o usuário aprove a autorização uma segunda vez depois de já a ter autorizado durante o primeiro login, clicando no botão.
Não, elas são mostradas uma vez e depois apenas um hash é armazenado.
A chave de API do usuário deve ser armazenada em seu aplicativo, preferencialmente no dispositivo do usuário final. Toda a razão para uma chave de API de usuário é que eles têm uma “prova” de autorização e são responsáveis por armazená-la.
Não acredito que seja possível recuperar o valor de uma chave de API via API. O Discourse não salva chaves de API não criptografadas no banco de dados. Mesmo que você pudesse recuperar o valor criptografado, não haveria como descriptografá-lo em seu aplicativo.
Você pode explicar um pouco mais seu caso de uso? Se uma chave de API de usuário já foi gerada para um usuário, não está claro para mim por que ele precisaria aprovar a autorização uma segunda vez.
Relendo minha postagem, vejo que não expliquei como a variável $json foi definida para a solicitação. A maneira mais fácil de descobrir como estruturar os dados é fazer uma solicitação para gerar uma única chave de API de usuário com os escopos que você deseja usar através da interface do Discourse, em seguida, observe o valor da carga útil da solicitação que é enviada com a solicitação para /admin/api/keys:
Olá @simon, obrigado pela sua resposta. Deixe-me explicar nosso caso com mais detalhes.
Estamos construindo um aplicativo móvel que depende da lógica de backend dos endpoints do Discourse. Quando um usuário faz login através do aplicativo, os dados de login são enviados para a API do Discourse via session.json, que retorna um cookie. Este cookie é então usado para redirecionar o webview para /user-api-key/new, solicitando que o usuário aprove a autorização. Após a aprovação, o payload é descriptografado em chaves de API.
Neste caso, podemos usar as chaves de API como um token global dentro do aplicativo móvel para acessar outros endpoints do Discourse. No entanto, quando o usuário faz logout, o token deve ser removido do estado global para que ele não possa acessar endpoints como a criação de um novo tópico.
Minha pergunta é sobre este tópico: como podemos verificar se um usuário já possui user_api_keys e se elas ainda estão ativas? Se as chaves existirem e estiverem ativas, o usuário poderá usá-las após o login. Caso contrário, o usuário precisará criar novas user_api_keys, o que exigiria aprovação no webview.
Este é o principal problema que estou enfrentando.
Também me referi à postagem Gerar chave de API de usuário sem aprovação do usuário - #2 por simon, que inicialmente consultei para implementação de chaves de API. No entanto, o problema permanece o mesmo: quando verificamos /admin/api/keys, não conseguimos recuperar o valor das chaves de API já salvas no banco de dados ou obter chaves de API por usuário. Acredito que, para esta implementação, precisaríamos armazenar as chaves de API em nosso próprio banco de dados.
Talvez você possa gerar um token de sessão que seja separado da chave de API. Use esse token para indicar o status de login do usuário. Dessa forma, você não precisaria excluir a chave de API quando o usuário fizer logout.
Obrigado pela sua contribuição neste problema. Concordo que é melhor armazenar o token em dois lugares: primeiro, no estado global para verificar o status de login do usuário e, segundo, no banco de dados para armazenar as user_api_keys.
Olá, obrigado pela sua sugestão. O motivo pelo qual não estamos usando o Discourse Connect aqui é que não estamos conectando o Discourse a nenhum outro site ou local. Toda a funcionalidade de login será tratada diretamente através do Discourse, e o aplicativo interagirá apenas com o Discourse.
Seu aplicativo é outro lugar. Tenho certeza de que você quer configurar seu aplicativo para ser um cliente do Discourse Connect para que as pessoas possam fazer login no seu aplicativo fazendo login no Discourse. Então seu aplicativo pode interagir com o Discourse, eu acho. Ou talvez eu não entenda como os aplicativos funcionam.
