Je pense que c’est déjà comme ça que ça fonctionne si vous n’avez pas d’SSO : un utilisateur invité par e-mail n’a pas besoin d’activer son e-mail, car le lien d’e-mail lui-même compte comme l’activation.
Cependant, j’utilise WordPress comme SSO et si j’invite quelqu’un, il y a un processus laborieux consistant d’abord à être redirigé vers l’écran de connexion, à devoir cliquer sur s’inscrire, remplir le formulaire, puis à devoir valider mon e-mail, puis lorsque vous arrivez enfin sur le forum, vous devez cliquer sur « se connecter », tout cela avant de pouvoir y accéder.
Y a-t-il un moyen pour moi de :
Faire en sorte que le lien d’invitation redirige par défaut vers ma page S’inscrire et non vers la page de connexion
Salut, désolé pour la confusion, je veux dire en utilisant le système d’invitation de Discourse.
Je veux encourager les gens à inviter leurs amis et à obtenir les badges qui y sont liés. Mais actuellement, le processus d’inscription est très fastidieux après avoir été invité.
Aussi, pour information, j’avais configuré pour que les personnes invitées soient TL1, mais cela a été ignoré lors de mes tests et elles ont été définies sur TL0.
Autant que je sache, il n’est pas actuellement possible pour un client fournisseur DiscourseConnect de faire la distinction entre une demande de connexion provenant d’une invitation et une demande de connexion provenant d’une connexion normale. En d’autres termes, voici comment cela fonctionne
L’utilisateur A crée une invitation dans Discourse.
L’utilisateur B accède au lien d’invitation (dans Discourse).
Comme DiscourseConnect est configuré, Discourse redirige l’utilisateur B vers Wordpress.
Actuellement, je ne pense pas qu’il soit possible pour le plugin WP Discourse de faire la distinction entre une requête entrante comme la 3 (c’est-à-dire une redirection à partir d’une invitation) et une requête entrante lorsque l’utilisateur clique simplement sur « se connecter » dans Discourse. En d’autres termes, vous devriez rediriger toutes les demandes d’authentification entrantes vers l’enregistrement, ce qui n’est probablement pas ce que vous voulez.
@david Je vérifie juste, est-ce que c’est correct ?
@Shauny En bref, il faudrait une mise à jour du protocole DiscourseConnect lui-même (c’est-à-dire son fonctionnement dans Discourse) pour que le flux d’invitation fonctionne comme vous le souhaitez.
Supprimer l’e-mail de vérification, en plus d’être peu sûr, pose le même problème.
Il n’y a aucun moyen de distinguer le scénario que vous envisagez d’autres scénarios du côté de Wordpress. Même si cela était possible, ce ne serait toujours pas conseillé car vous pouvez partager un lien d’invitation sans jamais l’envoyer par e-mail à quelqu’un.
Ainsi, la redirection automatique vers l’enregistrement peut être possible s’il y a une mise à jour du protocole DiscourseConnect, mais la suppression de la vérification par e-mail n’est probablement pas possible (sans compromettre la sécurité de votre site).
Mais si vous envoyez le lien d’invitation par e-mail et qu’ils cliquent sur le lien de l’e-mail, vous avez déjà vérifié leur adresse e-mail. Si vous n’utilisez pas l’authentification unique (SSO), tout cela fonctionne et aucune vérification d’e-mail supplémentaire n’est requise !
D’après ce que je comprends, dans son état actuel, il n’y a aucun moyen pour Discourse de dire au fournisseur SSO que l’e-mail a été vérifié par une invitation, et le SSO ne le dit pas non plus à Discourse.
Il devrait vraiment y avoir un moyen de supprimer l’activation par e-mail dans le produit principal. J’ai configuré Discourse avec SSO et l’étape de vérification par e-mail ajoute beaucoup de friction pour les nouveaux utilisateurs.
Il existe ce plugin qui le désactive, mais malheureusement, je n’ai pas accès pour installer des plugins là où j’héberge (et il ne semble pas fonctionner pour tout le monde) : Disable Email Verification for Discourse Plugin
Il est assez frustrant de ne pas pouvoir désactiver l’activation par e-mail et il y a de nombreux messages au fil des ans avec différentes personnes qui luttent contre cela. Le produit principal devrait permettre aux administrateurs d’exécuter un serveur comme ils le souhaitent.