La SPA no tiene gestión de usuarios propia, me gustaría usar Discourse para eso (porque no tenemos ninguna otra cosa específica del usuario que necesite una gestión de usuarios propia).
Pero me gustaría mostrar el usuario actualmente conectado de Discourse en la SPA, así como mostrar un widget de los temas no leídos (que son específicos del usuario), por ejemplo, por lo que necesito cargar datos a través de la API de Discourse.
Cosas que he intentado:
Usar la ruta SSO de Discourse, que luego redirige de vuelta a mi SPA. Está bien, obtengo la dirección de correo electrónico del usuario actual, el ID externo, etc., pero nada con lo que pueda solicitar (token / clave).
Jugar con la configuración de las cookies para poder usar la cookie de Discourse para hacer la solicitud (sin éxito).
He leído sobre la clave API de usuario en User API keys specification, pero me parecería extraño que el usuario permitiera que una aplicación, que es el mismo sitio, acceda a su cuenta de Discourse.
¿Hay alguna posibilidad de lograr el comportamiento que deseo?
Crea una clave de API con los ámbitos que necesites y acceso a “todos los usuarios”.
Obviamente, no puedes pasar esa clave a la aplicación web en el lado del cliente sin comprometer el sitio, por lo que necesitarás reenviar las solicitudes de la aplicación web a través del backend de esa aplicación a tu instancia de Discourse. (Y necesitarías validar que el nombre de usuario es legítimo desde el backend; no he mirado DiscourseConnect, pero presumiblemente hay una manera de hacerlo).
(PD: Recomiendo usar ‘example.com’ para tu dominio de ejemplo. Alguien podría comprar el que has enlazado y configurar spam o malware o lo que sea, mientras que example.[com|org|net] están oficialmente reservados.)
Sí, esa es la forma en que solía implementarlo ahora.
Envío al usuario a través del SSO, el Middleware crea un usuario simple con nombre, correo electrónico y una matriz de tokens, crea un token, lo devuelve al SPA.
El middleware proxy las solicitudes a Discourse con una clave de API de todos los usuarios y valida el “token de sesión” (para ver qué usuario es) y algo de otra magia de seguridad.
Para que el usuario permanezca conectado, usaré una cookie / almacenamiento local y sincronizaré el cierre de sesión a través de la opción de cierre de sesión directa de Discourse.
Funciona, pero todavía creo que debería haber una mejor opción que manejarlo con un token de API de administrador en combinación con un nombre de usuario. Se rompe si algún administrador cambia el nombre de usuario de alguien… Me gustaría un ID hash o algo así… Pero nada que pueda cambiar, ¡así que me conformaré con eso!)