Nous utilisons OpenID pour la connexion, et il semble que cette option ne soit disponible qu’en utilisant DiscourseConnect. Existe-t-il une autre méthode ? Les remplir manuellement est assez ennuyeux.
Nous autorisons les utilisateurs à modifier leur adresse e-mail (distincte du SSO) sur les sites Discourse, mais l’identifiant utilisateur est garanti d’être le même.
Ma réponse initiale (les questions sont toujours en suspens)
Salut @mattdm, pourriez-vous clarifier quelques points :
L’e-mail d’un utilisateur peut-il être différent entre ses comptes sur WordPress et Discourse ?
Que voulez-vous dire par « l’identifiant utilisateur est garanti d’être le même » ? De quel identifiant utilisateur parlons-nous ?
Oh, désolé — j’étais sûr d’y avoir répondu avant, mais je suppose que… non ? J’y ai peut-être juste pensé ! Quoi qu’il en soit :
L’e-mail est initialement synchronisé depuis le SSO pour WordPress et Discourse. Cependant, à la demande générale, nous autorisons les utilisateurs à modifier cet e-mail sur Discourse. (Il s’avère fréquent de vouloir que les notifications Discourse soient envoyées ailleurs que sur l’e-mail directement associé à la connexion.) Il est également possible de modifier l’adresse e-mail sur WordPress, mais je ne connais personne qui le fasse, ni même si l’e-mail sortant sur cette instance fonctionne.
Par « user id », j’entendais « username ». Le nom d’utilisateur est toujours[^1] tiré du SSO pour Discourse et WordPress et ne peut être modifié par l’utilisateur dans aucun des deux cas. Pour une raison qui m’est inconnue mais qui avait probablement du sens à l’époque, il s’agit du nickname côté SSO ; ceci est mappé à oauth2 json username path.
[^1] : En fait, il s’avère qu’il existe quelques comptes comme le mien qui ont été configurés avant que nous ayons le SSO, et ils sont incorrects — je suis « Matthew Miller » au lieu de mattdm. Mais nous pourrions corriger cela.
Il y aurait un sous-ensemble de vos utilisateurs avec des e-mails différents sur WordPress et Discourse.
Votre nom d’utilisateur est garanti d’être le même car il est fourni par votre fournisseur d’identité pour WordPress et Discourse.
Si nous devions découpler le webhook utilisateur WP Discourse de la fonctionnalité DiscourseConnect (possible), la correspondance des utilisateurs se ferait sur la base de l’e-mail, et non du nom d’utilisateur. Votre situation est quelque peu spécifique à votre configuration d’identité.
Je pense que ce cas est mieux géré par du code personnalisé sur votre WordPress. Ce que vous voulez, c’est quelque chose comme ceci :
Essentiellement, attribuez simplement le champ méta discourse_username comme nom d’utilisateur WP après la connexion, car ils sont garantis d’être identiques. Notez que “user_login” est ce que le “nom d’utilisateur” est parfois appelé dans le code WordPress.
Je reviens sur ce sujet plusieurs années plus tard.
Quelque part en cours de route, nous avons modifié les adresses e-mail pour qu’elles soient synchronisées de force depuis notre SSO (oauth2). Donc, nous devrions pouvoir faire correspondre de cette façon. (Et, même s’il y a pour une raison quelconque une discordance, il ne devrait pas y avoir de cas où un e-mail appartient à quelqu’un d’autre, donc au pire, cela échouerait, n’est-ce pas ?)
Y a-t-il une chance que le webhook utilisateur WP Discourse fonctionne simplement ?
À défaut… Je ne suis pas un expert WP, et notre WP est hébergé, donc je ne suis pas sûr que nous ayons une option facile pour personnaliser le plugin.
Juste une note, cela fonctionne actuellement. Vous demandez une nouvelle fonctionnalité
De plus, vous demandez une nouvelle fonctionnalité qui doit être examinée très attentivement. Je sais que j’ai dit que c’était possible il y a quelques années, cependant, je suis actuellement un peu réticent à le faire en tant que fonctionnalité principale du plugin, car une telle fonctionnalité devrait supposer que les adresses e-mail sont correctement validées sur WordPress, ce qui n’est pas nécessairement une hypothèse sûre.
Cela (la validation des e-mails WordPress) relève de la responsabilité de l’administrateur du site, cependant, un principe du développement open source est d’éviter de créer quelque chose qui entraînera de mauvais résultats dans un sous-ensemble (même un petit sous-ensemble) de cas, en supposant que vous n’avez aucun contrôle sur l’environnement. Ce problème est toujours présent, mais atténué, lorsqu’il est limité à DiscourseConnect.
J’y réfléchirai plus attentivement et je vous répondrai plus tard cette semaine.
Si la correspondance des e-mails est trop compliquée, j’ai l’impression que « Les noms d’utilisateur Discourse correspondent toujours à WordPress (et vice versa) » ne peut pas être si rare.
Même si quelqu’un n’a pas de système SSO qui suppose un nom d’utilisateur unique, il doit sûrement y avoir de nombreux petits sites avec, disons, des dizaines d’utilisateurs WordPress où cela est vrai par convention.
Il existe une solution existante pour cela. Discourse peut être configuré pour être le fournisseur DiscourseConnect pour WordPress (l’inverse de la configuration habituelle). C’est facile à configurer. Lorsqu’il est activé, un paramètre optionnel permet de synchroniser les comptes WordPress/Discourse en fonction de l’adresse e-mail de l’utilisateur.
Il y a même un lien ajouté à la page de profil de l’utilisateur :
(edit : une image peut-elle être légendée sans IA ?)
En testant maintenant, cliquer sur le lien de la page de profil ne remplit pas le champ Nom d’utilisateur Discourse. Il devrait le faire. Cliquer sur le lien « Se connecter avec Discourse » qui peut être ajouté à la page de connexion entraîne la mise à jour automatique du champ Nom d’utilisateur Discourse.
Je pense que l’objectif de la synchronisation des comptes est de mettre à jour le champ Nom d’utilisateur Discourse de manière sécurisée, il vaut donc probablement la peine d’examiner ce qui se passe à ce sujet. Il semble également y avoir un problème où les comptes ayant une adresse e-mail « non vérifiée » sur WordPress sont autorisés à synchroniser leurs comptes avec Discourse. Cela ne devrait probablement pas être autorisé par défaut.
Dans votre cas, vous ne voudrez peut-être pas autoriser les utilisateurs à se connecter à WordPress via Discourse. Il devrait être possible d’utiliser simplement le lien sur la page de profil pour permettre aux utilisateurs de synchroniser leurs comptes afin que leur champ Nom d’utilisateur Discourse soit automatiquement rempli. Vous ne devriez pas avoir à activer la connexion à WordPress via Discourse pour que cela fonctionne.
Un inconvénient possible de cette approche est que les utilisateurs devront l’initier. Cela ne fournirait pas de bouton que les administrateurs pourraient cliquer pour obtenir le nom d’utilisateur Discourse d’un utilisateur.
Cela semble idiot. Nous avons un SSO centralisé. Nous ne devrions pas avoir à configurer certains de nos services pour utiliser d’autres services aléatoires comme fournisseur d’authentification juste pour les faire fonctionner ensemble. C’est une voie vers la folie.
Ne vous laissez pas tromper par le nom (DiscourseConnect). Si la fonctionnalité que j’ai décrite fonctionnait comme elle le devrait, ce serait simplement un moyen pour un utilisateur WordPress de confirmer qu’il avait un compte Discourse avec une adresse e-mail correspondante et d’obtenir automatiquement son nom d’utilisateur Discourse rempli dans WordPress. Cela n’affecterait pas le système d’authentification de votre site.
Il n’y aura jamais de mécanisme d’identité correspondant entre un nom d’utilisateur Wordpress et un nom d’utilisateur Discourse dans le plugin principal, même derrière un paramètre. La seule possibilité dans ce contexte est la correspondance par e-mail. J’ai décidé d’ajouter la correspondance par e-mail comme mécanisme de secours au webhook utilisateur. Elle sera dans la prochaine version, qui arrivera dans quelques semaines.
Pour clore la boucle sur ce sujet, la dernière version du plugin 2.5.4 comprenait diverses mises à jour des Webhooks, notamment la suppression de l’exigence DiscourseConnect pour le paramètre « Associer les utilisateurs par e-mail ». Voir plus loin
