La SPA n’a pas de gestion d’utilisateurs propre, j’aimerais utiliser Discourse pour cela (car nous n’avons rien d’autre spécifique à l’utilisateur qui nécessiterait sa propre gestion d’utilisateurs).
Mais j’aimerais afficher l’utilisateur actuellement connecté de Discourse dans la SPA, ainsi que l’affichage d’un widget des sujets non lus (qui sont spécifiques à l’utilisateur), par exemple, j’ai donc besoin de charger des données via l’API de Discourse.
Choses que j’ai essayées :
Utiliser le chemin SSO de Discourse, qui redirige ensuite vers ma SPA. C’est bien, j’obtiens l’adresse e-mail de l’utilisateur actuel, son identifiant externe, etc. - mais rien que je puisse utiliser pour la requête (token / clé).
Jouer avec les paramètres des cookies pour pouvoir utiliser le cookie Discourse pour effectuer la requête (sans succès).
J’ai lu sur la clé API utilisateur à l’adresse User API keys specification, mais je trouverais étrange que l’utilisateur autorise une application, qui est le même site, à accéder à son compte Discourse.
Y a-t-il une possibilité d’obtenir le comportement que je souhaite ?
Utilisez DiscourseConnect (« Discourse SSO ») comme décrit pour obtenir le nom d’utilisateur de l’utilisateur actuel.
Créez une clé d’API avec les autorisations dont vous avez besoin et un accès « tous les utilisateurs ».
Évidemment, vous ne pouvez pas transmettre cette clé à l’application web côté client sans compromettre le site, vous devrez donc relayer les requêtes de l’application web via le backend de cette application à votre instance Discourse. (Et vous devrez valider que le nom d’utilisateur est légitime depuis le backend — je n’ai pas examiné DiscourseConnect mais il y a probablement un moyen de le faire.)
(PS : Je recommande d’utiliser « example.com » pour votre domaine d’exemple. Quelqu’un pourrait acheter celui que vous avez lié et y installer du spam ou des malwares, alors que example.[com|org|net] sont officiellement réservés.)
Oui, c’est d’ailleurs comme ça que j’avais l’habitude de l’implémenter maintenant.
En passant l’utilisateur par le SSO, le Middleware crée un utilisateur simple avec nom, email et un tableau de tokens, crée un token, le renvoie au SPA.
Le middleware proxy les requêtes vers Discourse avec une clé API d’administrateur et valide le “token de session” (pour voir de quel utilisateur il s’agit) et d’autres astuces de sécurité.
Pour que l’utilisateur reste connecté, j’utiliserai un cookie / stockage local et synchroniserai la déconnexion via l’option de déconnexion directe de Discourse.
Ça fonctionne, mais je pense toujours qu’il devrait y avoir une meilleure option que de gérer avec un token API d’administrateur en combinaison avec un nom d’utilisateur. Ça casse si un administrateur change le nom d’utilisateur de quelqu’un… J’aimerais un ID hash ou quelque chose comme ça… Mais rien que je puisse changer, donc je vais faire avec
