Les connexions locales sont désactivées (les connexions via Facebook et Google sont configurées)
Le personnel doit approuver tous les nouveaux comptes d’utilisateurs
Nous disposons d’une grande liste de diffusion par e-mail et souhaitons « pré-approuver » toutes les adresses e-mail de cette liste. Si une personne se rend sur le site et tente de s’inscrire ou de se connecter avec un compte Facebook ou Google associé à une adresse e-mail figurant sur notre liste de pré-approbation, elle n’a pas besoin d’attendre l’approbation d’un membre du personnel et peut immédiatement commencer à utiliser le site.
Idéalement, nous aimerions également pouvoir pré-configurer l’appartenance à des groupes par e-mail.
Est-ce possible ? Les solutions nécessitant l’utilisation de l’API Discourse sont les bienvenues.
Je crains que cela ne fonctionne pas du tout !
Principalement parce que les invitations ne fonctionnent pas sans que les connexions locales soient activées. Vous devrez probablement envisager un plugin très personnalisé qui gérera tout cela ou un système d’authentification externe pour répondre à vos besoins.
Je pense que si vous importez les adresses avec un script d’importation, la bonne chose se produira. Vous devrez vous assurer que ces utilisateurs ne sont pas marqués comme actifs, sauf si vous voulez risquer de les inonder de notifications et de résumés.
Cela devrait être assez facile à faire depuis la console. Je pense que cela pourrait être fait via l’API si vous êtes hébergé quelque part.
« Grand » signifie environ 5 000 — suffisamment pour que nous ne voulions pas le saisir manuellement dans l’interface utilisateur quelque part.
@pfaffman, pourriez-vous préciser un peu comment je pourrais créer des utilisateurs via l’API ? Il semble que le champ « mot de passe » soit obligatoire pour créer des utilisateurs, ce que je suppose ne peut pas être fait si la connexion locale est désactivée : POST /users
Pour développer un peu le cas d’usage, pour d’autres qui pourraient envisager quelque chose de similaire : nous souhaitons encourager les utilisateurs à se connecter avec leur compte social — beaucoup des personnes que nous cherchons à engager sur Discourse ne sont pas technophiles et nous voulons qu’ils sachent qu’ils n’ont pas besoin de gérer un autre nom d’utilisateur et mot de passe.
Cependant, la fonctionnalité actuelle d’invitation par e-mail dans Discourse oblige l’utilisateur à choisir un mot de passe, ce qui va à l’encontre de notre objectif de garder les choses simples pour nos utilisateurs.
Existe-t-il peut-être une autre façon d’atteindre notre objectif ? Je ne suis pas opposé à activer la connexion locale si nécessaire, mais je veux que les utilisateurs invités voient clairement qu’ils peuvent se connecter avec un compte social et n’ont pas besoin de mot de passe du tout.
Merci à tous ! Je suis vraiment enthousiaste à l’idée de voir plus de personnes utiliser Discourse.
Le fait de ne pas leur permettre de créer un mot de passe tout en exigeant qu’ils vous indiquent l’adresse e-mail qu’ils utilisent pour la connexion sociale n’est tout simplement pas la même chose. Ils peuvent toujours éviter d’avoir un mot de passe s’ils utilisent une connexion sociale. Je refuse souvent de me connecter avec mon compte Gmail (bien que moins fréquemment maintenant) et ma femme refuse presque toujours cela. De plus, la connexion par e-mail est très pratique et signifie que vous n’avez jamais besoin de mot de passe. Mais je m’éloigne du sujet.
Si l’API exige un mot de passe, générez-en simplement un aléatoire. Avoir un mot de passe que vous ne connaissez pas et dont vous n’avez pas besoin est pratiquement équivalent à ne pas en avoir.
À un moment donné, j’ai créé GitHub - pfaffman/discourse-user-creator: Create an activated user, optionally assigning to group · GitHub ; je ne garantis pas qu’il fonctionne, mais il devrait vous rapprocher de l’objectif. Vous souhaitez créer des utilisateurs non activés, vous devrez donc le modifier, mais il devrait être assez clair ce qu’il faut supprimer. (Si vous souhaitez simplement résoudre le problème et avez un budget, n’hésitez pas à me contacter.)
Je dois admettre que je ne m’en suis rendu compte qu’à une inspection plus attentive : le champ mot de passe est facultatif pour les utilisateurs qui acceptent des invitations par e-mail. Vous avez raison de souligner que les utilisateurs devraient pouvoir choisir d’utiliser une autre adresse e-mail et de créer un mot de passe. Je me sentirais beaucoup plus à l’aise si l’interface indiquait clairement que le mot de passe est facultatif, surtout lorsque la connexion via un réseau social est activée sur le site. Avec l’interface actuelle, il faudrait vraiment ne pas vouloir créer de mot de passe pour découvrir que ce n’est pas strictement obligatoire, à mon avis. Je suppose que je devrais me mettre au travail et proposer une PR pour améliorer l’expérience utilisateur
J’ai examiné l’exemple de code, merci ! Pour ce que cela vaut, j’ai dû utiliser cette astuce pour effectuer les appels API appropriés : Using the API to create a user on an SSO only system - #13 by DylannCordel - même ainsi, je ne pense pas que cela réponde au cas d’usage que j’avais en tête, car cela déclenche un e-mail d’activation à l’utilisateur, ce que j’espérais éviter afin d’offrir une expérience transparente « qui fonctionne tout de suite » s’ils se connectent un jour au site.
J’ai également un peu expérimenté cette solution : How to manually add user in discourse? - #10 - je pense que cela pourrait fonctionner pour ajouter manuellement les comptes utilisateurs que je souhaite, mais au final, je ne suis pas sûr que cela vaille le risque de modifier directement l’environnement à l’intérieur du conteneur pour effectuer ces modifications.
Bref, dans l’ensemble, je pense que le flux de travail que j’espérais n’est pas vraiment pris en charge ou prévu, et je devrai m’en accommoder jusqu’à ce que l’interface soit améliorée (peut-être) à un moment donné.
Les connexions via les réseaux sociaux contournent le mot de passe, car l’authentification est gérée par Facebook, Twitter, Google, etc.
Les invitations rendent le mot de passe temporairement facultatif, mais vous devez suivre à nouveau le lien d’invitation pour vous « connecter ». Je pense que nous avons tellement verrouillé ce processus qu’il ne fonctionne plus vraiment. Vous devrez alors demander une réinitialisation de mot de passe par e-mail pour accéder à votre compte, ce qui implique de définir un mot de passe.
C’est une longue histoire, mais les invitations sont conçues pour permettre aux gens de se connecter et de répondre rapidement, avec un minimum de formalités. Elles ne sont en revanche pas destinées à permettre aux utilisateurs de ne jamais définir de mot de passe.
Envoyer une invitation par e-mail à un utilisateur (la connexion locale doit être activée pour que cette option soit disponible).
Lorsque l’utilisateur clique sur l’invitation, il peut laisser le mot de passe vide et se connecter immédiatement.
Lors de sa prochaine visite sur le site, s’il doit se connecter, il peut utiliser un compte social correspondant à cet e-mail.
Il est juste de dire que cela ne devrait peut-être pas fonctionner, et que mon commentaire précédent concernant une interface utilisateur peu claire est en réalité une fonctionnalité et non un bug conçu pour décourager les gens d’utiliser cette solution de contournement. Cela dit, cela semble être une voie acceptable pour un utilisateur invité par e-mail qui, au final, ne souhaite pas créer de mot de passe et préfère les autres avantages de la connexion sociale (par exemple, récupérer sa photo de profil).
Je comprends tout à fait le point précédent selon lequel certains utilisateurs souhaitent activement avoir un mot de passe plutôt que de se connecter via un réseau social, et je suis convaincu que je ne devrais pas désactiser cette option pour ceux qui la souhaitent. J’espère néanmoins toujours trouver un moyen simple et clair d’inviter ou de configurer des utilisateurs qui préfèrent ne pas avoir de mot de passe.
