Est-ce la seule chose que fait ce réglage ?
Je trouve qu’il est nommé et décrit de manière assez vague dans WP, alors je me demandais ce qu’il pourrait faire d’autre ?
À ce sujet,
qu’advient-il si un utilisateur existe déjà dans WordPress et Discourse ? Comment puis-je fusionner / connecter leurs profils ?
Techniquement, ce qu’il fait, c’est d’appeler la route sync_sso de Discourse et de passer leurs données (ID utilisateur WordPress, nom d’utilisateur, nom, e-mail…) à Discourse immédiatement après leur connexion à WordPress. Les détails sur la route sync_sso sont ici : Sync DiscourseConnect user data with the sync_sso route.
Le seul effet secondaire dont je suis conscient pour les utilisateurs WordPress qui n’ont jamais visité le site Discourse est qu’ils commenceront à recevoir des e-mails de résumé de Discourse.
C’est pourquoi vous voulez encourager vos utilisateurs Discourse à s’inscrire sur WordPress avec la même adresse e-mail que celle qu’ils utilisent sur Discourse. Tant que les adresses e-mail correspondent, ils seront connectés au bon compte Discourse. Cela suppose que vous avez résolu le problème de vérification des e-mails dont nous avons discuté dans les publications précédentes.
Il est probable que vous vous retrouviez avec des utilisateurs s’inscrivant sur WordPress avec des adresses e-mail différentes de celles qu’ils ont utilisées sur Discourse. Dans ce cas, un nouveau compte Discourse sera créé pour eux, en utilisant l’adresse e-mail WordPress. Vous devrez fusionner manuellement l’ancien compte Discourse dans le nouveau compte Discourse : Merging user accounts.
3 « J'aime »
Que se passe-t-il si nous devons mettre à jour manuellement l’e-mail d’un utilisateur dans WordPress ? Son e-mail Discourse est-il également mis à jour si ce paramètre est activé ?
1 « J'aime »
La mise à jour d’un utilisateur à partir de sa page de profil WordPress ne déclenche pas l’appel à sync_sso. Cela devrait probablement le faire cependant. Pour l’instant, vous devrez lui demander de se déconnecter de WordPress, puis de se reconnecter à WordPress. Je ne pense pas qu’il soit possible pour un administrateur de déconnecter un utilisateur WordPress depuis sa page de profil.
Si vous souhaitez synchroniser les e-mails et/ou les noms d’utilisateur entre WordPress et Discourse, activez ces paramètres Discourse :
auth overrides emailauth overrides username
1 « J'aime »
Merci Simon. Je pense que c’est le processus que je vais suivre après avoir tout considéré :
- Exporter les utilisateurs de Discourse
- Activer Discourse Connect
- Importer et créer ces utilisateurs dans Wordpress et marquer leurs e-mails comme vérifiés dans WP
- Lorsque ces utilisateurs se connecteront (via une page de connexion personnalisée), ils devront réinitialiser leur mot de passe
- Forcer d’une manière ou d’une autre uniquement ce segment d’utilisateurs à changer leur mot de passe après avoir entré leur e-mail (et que le système réalise qu’ils font partie de ce segment)
- OU simplement afficher un message sur la page de connexion : « si vous vous connectez après le [date], vous devez RÉINITIALISER votre mot de passe »
- L’accès devrait fonctionner !
Quant aux nouvelles inscriptions, je devrai trouver un moyen de vérifier les e-mails. Je leur enverrai probablement leurs mots de passe par e-mail.
J’ai également remarqué que même si le paramètre « Email Address Verified » n’est pas sélectionné dans le profil Wordpress, l’utilisateur peut toujours se connecter en SSO à Discourse. Ils doivent confirmer leur e-mail quoi qu’il arrive la première fois qu’ils accèdent à Discourse. Ce qui est bien.
Ces paramètres ont-ils des effets secondaires ?
1 « J'aime »
Oui, c’est ainsi que cela est censé fonctionner. Ce n’est pas une grande barrière pour la plupart des utilisateurs. Le problème dont vous devez être conscient est que si l’adresse e-mail n’est pas marquée comme vérifiée sur Wordpress, Discourse ne fera pas correspondre les utilisateurs Wordpress aux utilisateurs Discourse en fonction de leur adresse e-mail lors de leur première connexion à Discourse via DiscourseConnect. Tant que vous trouverez comment marquer les adresses e-mail de vos utilisateurs importés comme vérifiées, cela ne causera pas de problème. Si vous ne les marquez pas comme vérifiées, ce sera un casse-tête à régler.
S’ils sont activés, ils empêchent les utilisateurs de modifier leur nom d’utilisateur ou leur adresse e-mail sur Discourse.
1 « J'aime »
Oui, j’ai testé beaucoup de choses et je m’en suis rendu compte. Je vais juste écrire un script personnalisé qui marquera tous les utilisateurs que j’importe comme vérifiés.
Merci pour la clarification !
1 « J'aime »
Est-il acceptable de laisser le mode détaillé /logs activé en permanence ?
Cela aura-t-il un impact négatif sur les performances ?
J’ai vu des cas où ils ont été laissés activés en permanence. Je ne pense pas que cela ait un impact significatif sur les performances. Cela encombre simplement vos journaux si vous essayez de déboguer un problème qui n’est pas lié à DiscourseConnect.
2 « J'aime »
Tout a parfaitement fonctionné jusqu’à présent !
Une petite chose que je remarque, c’est que quel que soit le chemin que j’entre dans ce champ :
devient la page de connexion WordPress par défaut.
Par exemple, si j’essaie maintenant d’aller sur /wp-admin, ce que j’utilisais auparavant pour me connecter en tant qu’administrateur, cela me redirige vers /login/forum.
Idéalement, cela ne devrait rediriger vers ceci que lorsque quelqu’un clique sur le bouton de connexion depuis le forum Discourse.
Je me demande si c’est un comportement normal et si c’est une mauvaise chose que cela fonctionne ainsi.
C’est le comportement attendu. L’option « Chemin vers votre page de connexion » est utilisée pour remplacer le chemin de connexion WordPress par défaut. Elle le fait en s’accrochant au filtre WordPress login_url.
Il ne supprime pas la route de connexion par défaut à /wp-login.php, vous pouvez donc toujours accéder directement à cette URL en la saisissant dans la barre d’adresse de votre navigateur. Au lieu d’aller sur /wp-admin, allez sur /wp-login.php pour utiliser la page de connexion par défaut.
Je peux imaginer un moyen de mettre à jour le plugin pour qu’il ne redirige vers le chemin « Chemin vers votre page de connexion » que pour la connexion à Discourse, mais ce changement demanderait un peu de travail.
4 « J'aime »
Pas de souci. Juste une petite chose. Merci pour ces éclaircissements !
1 « J'aime »
Salut @simon, je vois les erreurs suivantes dans mon journal et je me demande ce qu’elles signifient et comment les résoudre. J’ai remarqué ces erreurs après qu’un utilisateur a signalé recevoir une erreur lors de sa tentative de connexion.
-
(google_oauth2) Échec d’authentification ! csrf_detected : OmniAuth::Strategies::OAuth2::CallbackError, csrf_detected | CSRF détecté
-
Échec d’authentification ! request_error : OAuth::Unauthorized, 401 Unauthorized
-
(facebook) Échec d’authentification ! no_authorization_code : OmniAuth::Strategies::Facebook::NoAuthorizationCodeError, doit passer soit un
code(via l’URL, soit par un cookie signéfbsr_XXX)
Il est à noter que ces erreurs ne sont pas fréquentes. La plupart des journaux semblent fonctionner correctement :
Je viens de recevoir cette capture d’écran de l’utilisateur :
Il a dit : « Il n’y a pas d’e-mail. Dès que vous cliquez sur le lien d’inscription, la page suivante s’affiche… »
Lorsque je clique sur le lien de connexion/inscription (en mode incognito), cela fonctionne pour moi.
Voici l’URL de notre forum à titre de référence : forum.projectvanlife.com
Je suppose que les entrées commençant par « Verbose SSO log » indiquent des connexions réussies.
Pour les erreurs « google_oauth2 », « OAuth::Unauthorized » et « facebook », je ne suis pas sûr de ce qui se passe. Votre site Discourse était-il précédemment configuré pour permettre aux utilisateurs de se connecter via Google et Facebook ? Si oui, ils ne pourront plus se connecter au site avec ces méthodes maintenant que DiscourseConnect est activé. Essayez peut-être de désactiver les connexions Google et Facebook depuis votre page de paramètres Discourse.
Pour les utilisateurs qui signalent des erreurs de connexion, essayez de trouver un message d’erreur détaillé dans le journal SSO qui est associé à la tentative de connexion de l’utilisateur. Ensuite, vérifiez si l’erreur correspond à l’un des problèmes décrits dans ce sujet : Debug and fixing common DiscourseConnect issues.
L’URL affichée dans la barre d’adresse du navigateur est https://projectvanlife.com/login/forum/javascript%3Avoid(0.
Je suppose qu’une partie du javascript est tronquée et qu’elle est en fait destinée à être décodée en javascript:void(0). Je ne suis pas sûr d’où cela pourrait provenir. Possiblement d’une des extensions du navigateur de l’utilisateur. Essayez de lui demander de désactiver ses extensions de navigateur, ou d’essayer de se connecter depuis une fenêtre de navigation privée.
Edit : @Sami_Syed le code javascript:void(0) est ajouté au chemin lorsque le lien « S’inscrire » de la page de connexion est cliqué. L’attribut href de ce lien est : \"javascript%3Avoid(0)\"
Je suppose que cela est utilisé pour que le formulaire d’inscription se trouve sur le même chemin que le formulaire de connexion. Cependant, quelque chose ne fonctionne pas correctement. Savez-vous si cela fonctionnait correctement avant l’activation de DiscourseConnect ?
Si le plugin utilisé pour les formulaires de connexion/inscription a une option pour que le formulaire d’inscription apparaisse sur une page séparée, l’activer devrait fonctionner comme une solution rapide au problème.
Je serai hors ligne la majeure partie de la journée, mais je pourrai essayer de vous aider plus tard si vous êtes bloqué.
Edit : J’étais perplexe à ce sujet, alors j’ai regardé de plus près. L’onglet « S’inscrire » sur le formulaire de connexion fonctionne sans problème. Le lien « S’inscrire » présente le problème que j’ai décrit ci-dessus :
La solution rapide au problème consiste donc simplement à supprimer le lien d’inscription.
2 « J'aime »
C’est exact.
Oui, c’était activé. La question est cependant, comment peuvent-ils même déclencher une connexion via FB ou Google maintenant ? Notre page de connexion actuelle n’a pas cette fonctionnalité.
Ou cette erreur se produit-elle pour ceux qui se sont inscrits à l’origine en utilisant G ou FB et qui essaient maintenant de se connecter mais cela ne fonctionne pas ?
Et si c’est le cas, comment puis-je résoudre ce problème ?
D’après ce que je vois, c’est parce que je n’y ai pas mis le bon lien. Oups. Bien vu et merci !
Je ne sais pas ce qui pourrait le déclencher. Peut-être que l’URL du fournisseur d’authentification a été mise en cache par les navigateurs de l’utilisateur. Ce n’est qu’une supposition, cependant.
1 « J'aime »
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.