Hola, me gustaría preguntar sobre user_api_keys. Actualmente, estoy trabajando en la integración de nuestra aplicación para usar las user_api_keys de Discourse para la autorización. Mi pregunta es: ¿hay alguna forma de recuperar user_api_keys usando la API?
Ahora mismo, después de iniciar sesión a través de /session.json y verificar el perfil del usuario actual usando /users/:username.json, podemos ver si el usuario tiene user_api_keys o no, pero no devuelve los valores reales:
La razón por la que quiero obtener el valor de user_api_keys es para evitar que el usuario tenga que aprobar la autorización una segunda vez después de haberla autorizado durante el primer inicio de sesión haciendo clic en el botón.
No, se muestran una vez y luego solo se almacena un hash.
La clave API del usuario debe almacenarse en tu aplicación, preferiblemente en el dispositivo del usuario final. La razón de ser de una clave API de usuario es que tengan una “prueba” de autorización y sean responsables de almacenarla.
No creo que sea posible recuperar el valor de una clave de API a través de la API. Discourse no guarda claves de API sin cifrar en la base de datos. Incluso si pudieras recuperar el valor cifrado, no habría forma de descifrarlo en tu aplicación.
¿Puedes explicar un poco más tu caso de uso? Si ya se ha generado una clave de API de usuario para un usuario, no me queda claro por qué necesitarían aprobar la autorización una segunda vez.
Al releer mi publicación, veo que no expliqué cómo se estableció la variable $json para la solicitud. La forma más fácil de averiguar cómo estructurar los datos es hacer una solicitud para generar una única clave de API de usuario con los ámbitos que deseas usar a través de la interfaz de usuario de Discourse, luego observar el valor de la carga útil de la solicitud que se envía con la solicitud a /admin/api/keys:
Hola @simon, gracias por tu respuesta. Permíteme explicar nuestro caso con más detalle.
Estamos creando una aplicación móvil que depende de la lógica del backend de los puntos finales de Discourse. Cuando un usuario inicia sesión a través de la aplicación, los datos de inicio de sesión se envían a la API de Discourse a través de session.json, que devuelve una cookie. Esta cookie se utiliza luego para redirigir la webview a /user-api-key/new, lo que solicita al usuario que apruebe la autorización. Después de la aprobación, la carga útil se descifra en claves API.
En este caso, podemos usar las claves API como un token global dentro de la aplicación móvil para acceder a otros puntos finales de Discourse. Sin embargo, cuando el usuario cierra sesión, el token debe eliminarse del estado global para que no pueda acceder a puntos finales como la creación de un nuevo tema.
Mi pregunta proviene de este tema: ¿cómo podemos verificar si un usuario ya tiene user_api_keys y si todavía están activas? Si las claves existen y están activas, el usuario debería poder usarlas después de iniciar sesión. Si no, el usuario necesitará crear nuevas user_api_keys, lo que requerirá aprobación en la webview.
También me referí a la publicación Generar clave API de usuario sin aprobación del usuario - #2 de simon, que inicialmente revisé para la implementación de claves API. Sin embargo, el problema sigue siendo el mismo: cuando verifico /admin/api/keys, no podemos recuperar el valor de las claves API ya guardadas en la base de datos ni obtener claves API por usuario. Creo que, para esta implementación, necesitaríamos almacenar las claves API en nuestra propia base de datos.
Quizás podrías generar un token de sesión que sea independiente de la clave de API. Usa ese token para indicar el estado de inicio de sesión del usuario. De esa manera, no necesitarías eliminar la clave de API cuando el usuario cierre la sesión.
Gracias por tus comentarios sobre este problema. Estoy de acuerdo en que es mejor almacenar el token en dos lugares: primero, en el estado global para verificar el estado de inicio de sesión del usuario y, segundo, en la base de datos para almacenar las user_api_keys.
Hola, gracias por tu sugerencia. La razón por la que no estamos utilizando Discourse Connect aquí es que no estamos conectando Discourse con ningún otro sitio web u otro lugar. Toda la funcionalidad de inicio de sesión se gestionará directamente a través de Discourse, y la aplicación solo interactuará con Discourse.
Tu aplicación es otro lugar. Estoy bastante seguro de que quieres configurar tu aplicación para que sea un cliente de Discourse Connect para que las personas puedan iniciar sesión en tu aplicación iniciando sesión en Discourse. Entonces tu aplicación puede interactuar con Discourse, creo. O tal vez no entiendo cómo funcionan las aplicaciones.
