Bonjour !
Nous envoyons une invitation Discourse à nos utilisateurs dès qu’ils créent un compte sur notre application. Nous disposons déjà de leur nom et des champs personnalisés nécessaires pour notre communauté, mais l’utilisateur doit les saisir à nouveau sur Discourse.
Existe-t-il un moyen de remplir ces champs automatiquement dans leur profil ?
Merci !
Je pense qu’il serait préférable que votre application serve de serveur SSO. Si ce n’est pas ce que vous souhaitez, vous pouvez alors créer l’utilisateur via l’API de votre application et inclure ces paramètres. Vous pouvez découvrir comment procéder grâce à Comment analyser l’API Discourse.
Nous ne souhaitons pas créer d’utilisateurs via l’API, car nous voulons que l’utilisateur crée son mot de passe et choisisse son nom d’utilisateur. J’ai envisagé de créer un utilisateur en attente avec toutes les données, mais cela semble impossible via l’API.
L’autre option qui me vient à l’esprit est d’étendre les invitations pour permettre des champs personnalisés et des informations de profil.
Peut-être un plugin qui récupère les champs de votre application via un webhook ou un appel API ? Vous pourriez configurer le plugin pour effectuer une requête du type get yoursite/user/<email_address> et remplir les champs utilisateur lorsque l’enregistrement de l’utilisateur est mis à jour. Quelque chose comme ça. L’authentification unique (SSO) semble toujours être la meilleure solution.
Oui, veuillez consulter Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso). C’est exactement le cas d’usage de la connexion unique (Single Sign On).
Avec le SSO, vous n’auriez cependant pas besoin de les inviter. Ils suffirait qu’ils visitent votre instance Discourse et seraient automatiquement connectés s’ils sont déjà connectés à votre application. S’ils ne sont pas déjà connectés à votre application, Discourse les redirigera vers votre application pour se connecter, puis ils seront automatiquement redirigés vers Discourse.
Le problème est que nous utilisons Discourse comme fournisseur SSO et cela fonctionne bien pour nous, mais oui, je suis d’accord, ce serait plus simple si Discourse consommait un fournisseur SSO.
@blake Je réfléchis toujours à la manière de procéder, puisque nous utilisons Discourse comme fournisseur SSO. Je ne souhaite pas migrer vers une autre solution pour le moment, car cela représenterait beaucoup plus de travail. As-tu d’autres idées ? Ce n’est pas un problème si nous devons écrire du code personnalisé, mais nous voulons effectuer le moins de modifications possible à notre configuration actuelle.
Merci !
Je suis juste confus par votre configuration et ces deux phrases, car dans ce cas, vous n’avez pas vraiment de Single-sign-on, mais plutôt un double-sign-on ?
Si Discourse était votre fournisseur SSO, les nouveaux utilisateurs de votre application devraient être redirigés vers Discourse en premier pour créer un compte, puis redirigés vers votre application une fois authentifiés. Ainsi, toutes les informations seraient centralisées en un seul endroit.
Alors, selon ma compréhension actuelle, je transformerais votre application en fournisseur SSO et laisserais Discourse le consommer. Ou alors, je redirigerais les utilisateurs de votre application vers Discourse pour s’inscrire en premier, avant de les renvoyer vers votre application, car apparemment ce n’est pas ainsi que la configuration est actuellement mise en place ?
Sinon, si vous souhaitez avoir une configuration de double-sign-on, dès qu’un utilisateur s’inscrit sur votre application, créez automatiquement son compte sur Discourse via l’API avec un mot de passe aléatoire que vous ne communiquerez jamais à l’utilisateur, et remplissez automatiquement les informations de son profil qu’il a saisies dans votre application. Ensuite, envoyez-le à la page de réinitialisation du mot de passe sur Discourse pour son nouveau compte, plutôt que de lui envoyer une invitation.
Nous effectuons l’inscription via notre application, mais celle-ci ne gère pas les sessions. Nous nous contentons de facturer l’utilisateur et de stocker ses informations dans notre base de données.
Nous devons obliger l’utilisateur à créer d’abord un compte, et c’est précisément cette étape que nous souhaitons supprimer pour rendre le processus aussi simple que possible.
C’est l’effort que nous ne voulons pas entreprendre, car ajouter la gestion des sessions, la récupération de mot de passe, l’authentification à deux facteurs (2FA) et toutes les fonctionnalités offertes par Discourse demanderait beaucoup de travail.
C’est précisément ce que nous ne voulons pas.
C’est ce que j’ai fait initialement, mais nous devrions définir un nom d’utilisateur aléatoire, ce que nous ne souhaitons pas. Bien que cela fonctionnerait, nous voulons que l’utilisateur puisse personnaliser son compte avant de commencer à utiliser la communauté.
Mais bon, je suppose que la réponse reste d’utiliser un fournisseur SSO externe. Je vais emprunter cette voie et arrêter de réfléchir à la manière d’exploiter Discourse pour le faire fonctionner comme nous le souhaitons.
Merci pour votre aide @blake !
Ou abandonnez votre application et laissez Discourse Subscriptions gérer les paiements ?