Nous aimerions intégrer Discourse dans nos systèmes existants, afin de ne plus dépendre de notre serveur Discord pour le support. Nous avons déjà notre propre système de comptes configuré, et nous aimerions le réutiliser si possible pour réduire les frictions. Cependant, les adresses e-mail ne sont pas obligatoirement uniques dans notre cas, seulement les noms d’utilisateur. Il semble que Discourse repose sur l’hypothèse que les e-mails seront globalement uniques, ce qui nous empêche de nous intégrer directement.
J’ai examiné DiscourseConnect qui semblait prometteur, mais il est indiqué :
Discourse utilise les e-mails pour faire correspondre les utilisateurs externes aux utilisateurs de Discourse
Ce qui ne fonctionnerait pas dans notre cas, car plusieurs comptes peuvent (et utilisent) la même adresse e-mail.
Nous avons ensuite examiné Discourse OAuth2 Basic qui, à première vue, ne nécessitait pas d’e-mail :
Le seul attribut obligatoire est id
Cependant, plus loin, il est toujours mentionné la saisie manuelle d’une adresse e-mail si elle n’est pas fournie par la source oauth :
Notez que j’ai omis le chemin de l’e-mail : SoundCloud ne fournit pas d’e-mail, donc l’utilisateur devra le fournir et le vérifier lors de sa première inscription sur Discourse
L’utilisation de Discourse serait-elle toujours viable dans notre cas ? Permettre aux utilisateurs de fournir manuellement une adresse e-mail lors de leur première connexion à Discourse serait acceptable dans notre cas, mais seulement si nous pouvons désactiver la possibilité d’utiliser une adresse e-mail lors du processus de connexion réel (nécessitant l’utilisation uniquement du nom d’utilisateur et du mot de passe), car nous ne pouvons pas mapper de manière fiable un e-mail à un utilisateur unique. Pouvoir désactiver cela complètement du formulaire de connexion réduirait les frictions de notre côté, car ce ne serait pas quelque chose que nous supporterions de toute façon, et nous aimerions empêcher les utilisateurs d’essayer de le faire.
Nous avons envisagé cela, mais nous ne savions pas comment cela affecterait le flux oauth ni si cela ajouterait des frictions à l’inscription/connexion. Ce type de changement serait invisible pour l’utilisateur, donc il ne pourrait pas se connecter à moins d’entrer cette adresse e-mail modifiée. Notre serveur de compte actuel ne serait pas non plus au courant de ces modifications, donc même s’il entrait l’e-mail modifié, nous ne pourrions pas le trouver dans nos enregistrements ?
Cela casserait également les utilisateurs qui utilisent déjà des alias d’e-mail, n’est-ce pas ?
À moins qu’ils ne se soient connectés avec le nom d’utilisateur.
Si vous autorisiez les connexions par e-mail (ce que je pense que vous ne pouvez pas faire avec DiscourseConnect), cela fonctionnerait simplement s’ils avaient un lien par e-mail envoyé.
Vous devriez le lui faire savoir. Je pense que ce serait la première étape.
Une autre option peu élégante serait de n’autoriser que le “premier” (quelle que soit la définition) utilisateur à se connecter à Discourse.
Une autre solution peu élégante serait de forcer les utilisateurs de votre système à obtenir des adresses uniques pour chaque compte.
Eh bien, oui. Bien sûr, ce serait le cas, et c’est ce que je vise. Je cherchais une solution qui interdise simplement la connexion par e-mail, laissant les connexions par nom d’utilisateur comme seule méthode. Je suis prêt à casser entièrement le support par e-mail (pas de notifications par e-mail par exemple) en donnant simplement des e-mails totalement faux du serveur oauth. Mais cela crée des frictions si la possibilité d’utiliser un e-mail pour se connecter est toujours disponible, car les utilisateurs tenteraient de le faire et échoueraient.
Cela nous obligerait essentiellement à suivre 2 e-mails distincts par utilisateur, ce qui n’est pas souhaitable non plus, et comme mentionné par @supermathie, ce n’est même pas garanti de fonctionner avec tous les fournisseurs, et cela crée toujours des frictions car nous devrions maintenant informer les utilisateurs de cette adresse e-mail spécifique au forum dont ils doivent se souvenir.
Oui, cela fonctionnerait techniquement. Mais pour des raisons évidentes, ce ne serait pas une vraie solution à utiliser, car cela empêcherait tous les autres de rejoindre le forum.
Ce n’est pas quelque chose que nous pouvons faire pour des raisons techniques. La plus évidente étant que nous avons déjà des utilisateurs qui ont la même adresse e-mail que d’autres comptes. Mais la plus importante est que nous ne pouvons tout simplement pas le faire. Le projet dans lequel nous cherchons à intégrer Discourse est Pretendo Network, un projet d’émulation de serveur pour Nintendo Network. Nintendo a autorisé son système de compte à réutiliser les adresses e-mail, et donc pour émuler les serveurs avec précision, nous devons également le faire. Forcer des e-mails uniques n’est tout simplement pas dans nos cordes.
Quelqu’un de mon équipe a suggéré que nous exécutions notre propre serveur SMTP qui gère la cartographie des faux e-mails pour Discourse vers les vrais e-mails de nos utilisateurs, en transmettant les e-mails envoyés par Discourse de cette façon. Cela fonctionnerait, mais cela représente évidemment un coût technique plus élevé pour nous et ne résout toujours pas le problème de la désactivation de la connexion par e-mail et des frictions mentionnées précédemment dans notre cas.
Il semble que nous devrons peut-être simplement forker Discourse ou utiliser une autre solution de forum pour faire ce dont nous avons besoin.
Je me fie à ma mémoire, mais vous pouvez utiliser DiscourseConnect avec des adresses e-mail fausses mais uniques. Si les noms d’utilisateur sont garantis d’être uniques de votre côté, l’implémentation pourrait être assez simple. L’adresse e-mail pourrait être définie sur quelque chose comme username@invalid.com.
Les utilisateurs se connecteront à votre système avec la méthode qu’ils utilisent actuellement. Votre système générera alors la charge utile SSO avec l’adresse e-mail fausse.
L’inconvénient de cette approche est que vous devrez désactiver les e-mails sur Discourse. Cela peut être fait en réglant le paramètre disable emails sur yes ou sur non-staff (si vos membres du personnel ont des adresses e-mail uniques).
Vous pourriez également envisager d’utiliser des adresses e-mail avec + pour les utilisateurs ayant des adresses e-mail en double. La dernière fois que j’ai vérifié, Discourse considérait les adresses e-mail avec + comme uniques. Assurez-vous simplement d’encoder les adresses e-mail en URL avant de les utiliser dans la charge utile DiscourseConnect. Le risque ici est que si les utilisateurs ont des adresses e-mail en double et utilisent un serveur de messagerie qui ne prend pas en charge les adresses e-mail avec +, ils ne recevront pas d’e-mails de Discourse, mais cela permettrait à vos autres utilisateurs de recevoir des e-mails de Discourse.
Oui, mais seulement dans un cas particulier. Si un utilisateur a créé un compte Discourse avant que le site Discourse n’ait implémenté DiscourseConnect, Discourse tentera d’associer les utilisateurs existants à l’adresse e-mail présente dans la charge utile DiscourseConnect. Si vous démarrez un nouveau site Discourse, ce ne sera pas un problème.
Un autre cas où j’ai vu le problème de correspondance d’e-mails apparaître est lorsque, en raison d’un code défectueux sur le site du fournisseur d’authentification, les enregistrements SSO sur le site Discourse sont devenus corrompus. Dans ce cas, le site a pu supprimer tous les enregistrements SSO côté Discourse, puis faire en sorte que Discourse associe les utilisateurs à l’adresse e-mail de la charge utile SSO lors de leur prochaine connexion. Discourse a ensuite généré de nouveaux enregistrements SSO pour les utilisateurs. Cela fonctionnerait toujours avec des adresses e-mail fausses.
La logique de l’authentification DiscourseConnect est que Discourse tente d’abord de trouver l’utilisateur en fonction du champ external_id de la charge utile. S’il ne trouve pas d’utilisateur, il essaie de trouver l’utilisateur en fonction du champ email de la charge utile. S’il ne trouve toujours pas d’utilisateur, il génère une erreur.
Vérifiez tout cela avant de l’implémenter sur un site réel, mais je sais que l’approche des adresses e-mail fausses a été utilisée sur des sites de production pour des cas où les adresses e-mail réelles des utilisateurs ne peuvent pas être partagées avec le site Discourse.
@simon Merci pour ces informations ! Je commence à penser que nous avançons.
C’est bien, et j’ai mentionné plus tôt que c’est une solution acceptable pour le problème “tous les e-mails doivent être uniques”. Je suis tout à fait d’accord pour désactiver essentiellement les e-mails dans notre cas, et utiliser de faux e-mails était une solution à laquelle j’étais parvenu avant de poster ceci.
Je n’ai peut-être pas été clair à l’origine, mais le but de ce post était de savoir s’il était possible de forcer l’invite de connexion à n’accepter que les noms d’utilisateur, car actuellement la connexion peut se faire avec un nom d’utilisateur ou un e-mail. Si les connexions par e-mail sont toujours affichées comme disponibles sur l’invite de connexion de Discourse, nos utilisateurs pourraient essayer d’utiliser leur adresse e-mail de compte existante et se heurter à une erreur. Nous devrions donc soit simplement gérer les gens qui essaient, et échouent, d’utiliser leur adresse e-mail actuelle, soit d’une manière ou d’une autre informer l’utilisateur de son nouvel e-mail spécifique au forum. Les deux peuvent causer de la confusion et des frictions pour les utilisateurs, donc idéalement, nous pourrions simplement restreindre l’invite de connexion à n’accepter que les noms d’utilisateur.
Avoir des e-mails uniques pour le personnel n’est malheureusement pas non plus garanti, donc je ne voudrais pas m’y fier. Ce paramètre désactive-t-il uniquement l’envoi d’e-mails ? Ou désactive-t-il l’utilisation des e-mails dans leur ensemble, comme ce que je recherche avec l’invite de connexion ?
J’ai consulté la page DiscourseConnect plusieurs fois et je n’ai pas vu cette option. Y a-t-il peut-être un meilleur endroit pour consulter ce type de documentation ? Je n’ai vu aucun lien vers une documentation complète sur ce post, j’ai donc supposé que toutes les informations s’y trouvaient.
J’avoue que je n’ai pas encore configuré DiscourseConnect moi-même pour examiner les paramètres. J’espérais que la documentation suffirait à comprendre ce qui est possible et ce qui ne l’est pas, afin de ne pas avoir à configurer une instance de test complète du forum à moins que nous ne soyons sûrs de nous y engager. Mais il semble qu’il y ait encore des informations qui ne sont pas facilement disponibles, à moins que je n’aie manqué quelque chose d’évident ?
Cela a également été envisagé plus tôt dans ce fil de discussion, mais le problème demeure que nous devrions soit gérer les connexions par e-mail échouées, soit informer l’utilisateur de cette nouvelle adresse e-mail du forum. Supprimer cette friction était mon objectif principal. Si ce n’est pas possible ici sans forker Discourse lui-même, et que la seule solution est soit de gérer les connexions par e-mail échouées, soit de donner aux gens un nouvel e-mail à retenir, alors nous pourrions mieux nous en sortir avec une solution de forum différente.
Il semble que j’aie mal compris, ce n’est pas très clair d’après le post lui-même. Cependant, mon point en soulevant cela était d’illustrer la dépendance à l’unicité des e-mails, ce qui serait toujours un problème.
Ce n’était ABSOLUMENT pas clair d’après le post seul, à moins que je n’aie manqué quelque chose. Merci pour cette clarification ! Cela semble plus en phase avec ce que j’espérais.
Pour autant que je sache, il n’est pas possible de forcer l’invite de connexion Discourse à n’afficher que le champ nom d’utilisateur. Vous seriez également bloqué en essayant de trouver comment faire enregistrer les utilisateurs en premier lieu. C’est pourquoi je suggère DiscourseConnect.
Lorsque DiscourseConnect est activé, il devient le seul système d’authentification pour votre site Discourse. Lorsque les utilisateurs cliquent sur le bouton de connexion sur Discourse, ils sont automatiquement redirigés vers l’URL que vous avez ajoutée au paramètre du site discourse_connect_url. Votre système d’authentification prend le relais à partir de là. Cela signifie que si vous avez un site auquel les utilisateurs peuvent actuellement se connecter avec un nom d’utilisateur et un mot de passe, ils continueront à se connecter de cette manière.
Pour configurer cela, vous devez être en mesure d’ajouter du code au backend du site auquel les utilisateurs se connectent actuellement. Ce n’est pas très difficile à configurer. Il y a un bon exemple de code ici : wp-discourse/lib/sso-provider/discourse-sso.php at main · discourse/wp-discourse · GitHub. Vous pouvez également obtenir de l’aide sur ce forum.
Si l’ajout de code à votre site actuel n’est pas possible, vous pourriez également créer un petit site Web auquel les utilisateurs peuvent se connecter avec un nom d’utilisateur et un mot de passe, puis ajouter le code DiscourseConnect à ce site. Ce serait moins de travail que de forker Discourse.
Merci ! Il semble que j’aie eu une incompréhension fondamentale de DiscourseConnect. Je pensais que la page de connexion restait sur Discourse et qu’elle contactait simplement le serveur externe. Je n’étais pas au courant que l’utilisateur était dirigé vers une page de connexion différente de notre choix.
Mon incompréhension de DiscourseConnect semble avoir été le nœud du problème et de toute la confusion.
Si vous ne vous souciez pas que Discourse envoie des e-mails pour les notifications, vous pourriez faire en sorte que votre SSO fournisse à Discourse l’adresse e-mail game-username@bogus.invalid.
Il serait alors peut-être possible pour les utilisateurs d’ajouter une deuxième adresse e-mail réelle, puis de remplacer celle qui est bidon par la secondaire.
Mes excuses, je n’ai pas vu votre réponse hier soir
Je ne l’avais pas fait. Comme je l’ai dit plus tôt, nous ne voulions pas procéder à un déploiement de test avant de savoir que Discourse était utilisable. Donc, je n’avais rien essayé, jusqu’à présent nous nous contentions de lire vos fonctionnalités et de poser des questions ici lorsque les choses n’étaient pas claires. C’est une excellente nouvelle, je n’étais pas au courant que nous pouvions contrôler les choses à ce degré.
Honnêtement, il semble assez difficile de trouver une documentation réelle sur quoi que ce soit en dehors de l’API. Du moins du point de vue d’un nouvel utilisateur.
Il n’y a rien d’évident sur la page d’accueil de Discourse qui mènerait à une documentation, et tous les liens sur la page DiscourseConnect mènent soit à des pages sans rapport, soit de retour au message lui-même. Essayer de rechercher "documentation Discourse" sur les moteurs de recherche ne mène qu’à des pages comme Documentation - Discourse Meta, qui n’est que la catégorie du forum pour cela, pas une vraie page de documentation, et https://docs.discourse.org/ mais il s’agit de la documentation de l’API et elle ne contient rien concernant des fonctionnalités comme DiscourseConnect, semble-t-il.
Essayer de trouver ces informations de manière organique s’est avéré difficile.
Y a-t-il un endroit évident que j’ai simplement manqué où tout cela est expliqué ? Il semble que le plus proche que je puisse trouver est la catégorie du forum, car il y a de nombreux guides/tutoriels rédigés par le personnel et autres sur divers sujets. Mais réutiliser le forum pour se documenter ne me semblait pas correct ? N’y a-t-il pas une source de documentation dédiée pour les fonctionnalités/outils Discourse comme il y en a pour l’API Discourse ?
Correct, cela fonctionnerait. Comme indiqué à plusieurs reprises, l’utilisation d’un e-mail bidon du fournisseur oauth était quelque chose que nous avions envisagé avant même de publier ce message.
Mais cela ne résout pas à lui seul le problème « si un utilisateur voit dans l’invite de connexion que les e-mails sont acceptés, il essaierait de les utiliser et échouerait en raison d’un e-mail bidon ».
Cependant, j’ai juste eu un malentendu sur le fonctionnement de DiscourseConnect. Je pensais que le formulaire de connexion était toujours sur Discourse, et que Discourse contactait simplement le fournisseur oauth. @simon me l’a maintenant corrigé, je n’étais pas au courant que cela déplaçait physiquement l’utilisateur hors du site vers notre propre formulaire de connexion. Cela résout à lui seul pratiquement tous les problèmes que j’avais. Merci, cependant !
Même si vous voulez seulement tester et que vous n’avez pas l’intention de continuer à utiliser notre hébergement, n’hésitez pas à démarrer un site d’essai ! Cela ne nous dérange pas !
Merci pour ce retour - nous faisons un effort conscient pour améliorer cela.
Cela vous dérangerait-il si nous vous contactions pour en discuter davantage ?
Aucune des personnes avec qui j’ai travaillé n’a été mécontente de l’hébergement discourse.org. Si vous avez besoin d’auto-héberger pour une raison quelconque, vous pouvez vous connecter sur https://dashboard.literatecomputing.com/ et rejoindre le groupe « essai gratuit » et utiliser le tableau de bord gratuitement (si vous n’arrivez pas à comprendre comment rejoindre le groupe d’essai gratuit, vous aurez probablement besoin de plus de soutien que je ne suis disposé à en donner). Si vous êtes prêt à utiliser Digital Ocean et mailgun, il vous suffit d’entrer des clés API et un nom d’hôte.
J’ai eu honte de ne même pas avoir pensé à cette option ! C’est un bon point et nous allons probablement le faire pour des raisons de test.
J’avais regardé vos options d’hébergement plus tôt aujourd’hui, car ce serait plus facile que l’auto-hébergement, mais cela semble malheureusement hors de notre budget. Nous avons plus de 200 000 utilisateurs, donc le plan “Basic” n’est pas une option. Nous avons plus de 5 employés, donc le plan “Standard” n’est pas une option. Et en tant que projet FOSS, nous fonctionnons grâce à des dons, et nous avons à peine assez pour payer les factures et un seul développeur à temps plein, donc le plan “Business” est très hors de portée.
Utiliser l’essai pour des tests est cependant une idée fantastique, merci ! Nous auto-hébergeons déjà la plupart de nos services, même notre instance Mastodon, donc l’auto-hébergement de Discourse n’est pas un obstacle majeur.
Bien sûr ! Toujours heureux d’aider si je peux, ne serait-ce qu’en donnant mon avis. J’espère que cela n’est pas apparu comme trop négatif, car ce n’était pas l’intention, pour être clair.
Si cela vous intéresse, nous offrons un hébergement gratuit pour certains projets FOSS… vos effectifs sont plus élevés que nos limites, mais les personnes qui prennent la décision pourraient être en mesure de laisser passer cela.
(notez que notre définition de « personnel » ici est « Administrateurs » + « Modérateurs de site », et non « personnel de l’entreprise respective » - je serais curieux de connaître la définition du personnel dans votre esprit avant cela)
Merci ! J’avais manqué cela sur votre page de tarifs. Je viens de vérifier à nouveau et c’est enfoui tout en bas de la page Je vais examiner cela et en parler avec mes collaborateurs !
Notre définition de « personnel » dans ce cas couvre 2 rôles généraux :
Les personnes de notre équipe de développement principale (en tant que projet open source, cela peut fluctuer, car les personnes peuvent aller et venir, mais nous avons eu environ 5 à 10 développeurs actifs au fil des ans à tout moment)
Notre équipe de modération (des non-développeurs et des membres de la communauté qui modèrent nos services, tels que les matchs en ligne et notre implémentation Miiverse, ainsi que notre serveur Discord). Cela varie également.
Nous POURRIONS limiter cela à seulement 5 de nos développeurs, ce qui correspondrait à ces limites, mais cela nous obligerait à décider qui a et qui n’a pas les pleins droits sur le forum. Cela limiterait également le nombre de personnes capables de modérer les forums (nous avons introduit une équipe de modération distincte de l’équipe de développement afin de décharger cette tâche de nous-mêmes en premier lieu).
Je vais certainement aborder cela avec mes collaborateurs et voir ce qu’il en advient !
Je vais examiner cela et en parler avec mes collaborateurs !