Un nouveau paramètre d’option appelé invite_code a été ajouté.
Lorsqu’il est défini, tous les comptes en cours d’enregistrement doivent saisir le code d’invitation pour pouvoir créer un compte. Les utilisateurs sans ce code ne sont pas autorisés à s’inscrire.
Cette fonctionnalité est 100 % optionnelle !. Pour l’instant, elle n’est compatible qu’avec l’authentification locale, mais nous améliorerons cela dans les versions futures.
Si vous activez le code d’invitation global, il s’applique ; sinon, il ne s’applique pas et le code d’invitation n’apparaîtra pas dans la fenêtre de dialogue d’inscription.
Le code ne concerne pas les employés ou non-employés ; il s’agit à 100 % de l’inscription de nouveaux comptes.
Le cas d’usage consiste à publier sur WhatsApp ou dans un groupe privé Facebook…
Hé, j’ai configuré un forum pour toi. Utilise le code d’invitation « Bienvenue sur Discourse » pour créer un compte.
Puisque le site exige une inscription, seules les personnes disposant du code peuvent y accéder.
Nous pouvons certainement étendre cette fonctionnalité, mais j’ai un cas d’usage ultra urgent, alors je l’ai réalisé aujourd’hui et je l’affinerai la semaine prochaine.
Cela nécessite une modération manuelle de chaque compte. Ce paramètre est vraiment très utile pour ceux qui souhaitent tester avec quelques utilisateurs ou pour ceux qui organisent une promotion où l’accès au forum est un avantage. Un tel code d’invitation réduira presque considérablement la charge de travail des forums de projet pilote.
Parce que je dois approuver chaque e-mail individuellement et rester disponible 24h/24 et 7j/7 sur la file d’attente d’approbation, sans avoir la moindre idée de savoir s’il s’agit d’un bot aléatoire ou d’une personne qui devrait réellement avoir accès.
Avec un code d’invitation, je sais qu’au moins, ils possédaient un code d’invitation que j’ai partagé de manière privée.
+1 pour cette fonctionnalité, qui est extrêmement utile pour plusieurs communautés que je gère. Je comprends le point de vue de @codinghorror et @ondrej concernant l’approbation manuelle mentionnée ci-dessus, mais je pense que cela comble un vide qui existe entre l’invitation manuelle de tout le monde (site « sur invitation uniquement ») et l’approbation manuelle de tous les utilisateurs (site avec « approbation des utilisateurs »).
Nous ne souhaitons pas valider les utilisateurs. Nous voulons simplement publier un code dans un groupe Slack/Telegram/WhatsApp et permettre à chacun de l’utiliser. Parfois, quelques testeurs supplémentaires avant le lancement officiel ne font pas de mal.
Je trouve cela également très utile, surtout si la fonctionnalité est légèrement étendue pour permettre d’« attacher » des groupes à un code d’invitation spécifique, c’est-à-dire qu’une personne créant un compte avec un code particulier soit automatiquement ajoutée à un groupe spécifique.
Dans certains cas d’usage, cela pourrait également répondre à la demande de jetons d’invitation indépendants de l’adresse e-mail, qui revient de temps à autre…
Je suis un fan de cela sous des formes légèrement différentes, il faut juste quelques ajustements. S’il y a un besoin urgent (?) pour cela maintenant, alors je suppose que c’est acceptable ?
Je ne ressens pas personnellement que le domaine magique …
veuillez vous inscrire sur https://forum.this-is-my-magic-domain.org
est un niveau de protection d’inscription complètement inutilisable et totalement inefficace par rapport au mot de passe magique …
vous devez connaître le secret this-is-my-magic-password pour accéder à ce site
Il existe deux formes que je suis ravi de soutenir
Veuillez visiter amazing.forum.com et saisir le code d’invitation : fantastic pour accéder (implémenté)
Et
Veuillez visiter amazing.forum.com/register?code=fantastic pour vous inscrire et accéder au forum
Nous avons probablement dépassé la règle des 100 ici, étant donné que notre méthode générale pour résoudre ce problème consiste à placer les sites derrière une authentification HTTP de base.
Les deux sont assez similaires ; j’implémente la solution #1 pour l’instant, mais je reviendrai avec la #2.
La #1 présente l’avantage d’être un peu plus facile lorsque vous ne dépendez pas du copier-coller, par exemple en recevant les instructions sur WhatsApp puis en utilisant le bureau pour finaliser.
La #2 a l’avantage de réduire la saisie de fantastic et est pratique pour un partage par « e-mail » plutôt que par WhatsApp.
Vous ne voyez pas d’où vient forum.this-magic-domain.org ici ? Dans les deux cas, il s’agit exactement du même domaine que celui sur lequel se trouve le forum.
(Ceci est sur un site de développement avec must_approve_users activé, après validation par e-mail)
Cela devrait être facultatif à l’inscription et facultatif lors de la connexion tant que l’utilisateur n’est pas approuvé, car toute mesure qui impose à tous les utilisateurs de copier le code quelque part va provoquer des erreurs et nécessiter une intervention de l’administrateur.
Pourquoi avez-vous besoin d’un code d’approbation APRÈS avoir déjà créé un compte ?
Cela signifie-t-il que les bots enregistrent simplement des comptes inutiles que vous pouvez éliminer bien avant qu’ils ne polluent votre base de données ?
De plus, votre compte est déjà enregistré, il est peut-être déjà validé.
Et puis, WTF, d’où vient toute cette discussion sur les domaines secrets ?
Si nous activions cela sur Meta, par exemple :
Veuillez visiter meta.discourse.org et entrer le code HELLOMETA pour créer un compte.
Je me rends compte maintenant que j’ai simplement répété par inadvertance les points de @codinghorror du sujet précédent. (que je n’avais pas lus au moment de l’écriture, car cela se trouvait dans #feature:announcements)
Essentiellement, cela devrait s’appuyer sur must_approve_users + login_required plutôt que de créer un système entièrement parallèle. L’implémentation actuelle est acceptable en tant que solution de contournement pour nous permettre de surmonter la crise actuelle, mais elle devrait être corrigée.
Quelqu’un oubliera le code ou ne le consignera pas par écrit si vous le présentez lors d’une conférence. Ou alors, vous devrez faire tourner le code une fois que les vidéos de la conférence seront en ligne. Il est beaucoup mieux de demander dans votre groupe WhatsApp « quel compte est @test3 ? », d’obtenir une réponse affirmative, et de cliquer
plutôt que d’essayer de les guider pour qu’ils copient correctement le code dans le formulaire d’inscription. (note : ces captures d’écran sont prises après la validation par e-mail.)
Je pense que c’est bon, il nous reste simplement à peaufiner les détails. Il y a certainement des améliorations que je soutiens pleinement ici.
Premièrement, l’intégration avec la page des invitations aux utilisateurs, par exemple si vous vous inscrivez sur Meta en visitant le lien https://meta.discourse.org/signup?u=codinghorror, vous apparaîtrez comme quelqu’un que j’ai invité sur ma page de profil utilisateur, comme ceci :
Rappelez-vous que les invitations basées sur l’e-mail accordent déjà le niveau TL1 aux utilisateurs que vous avez invités… nous avons donc déjà cet avantage… jetez un œil à la boîte de dialogue d’invitation… remarquez que vous pouvez également ajouter un accès au groupe, et l’élévation du niveau TL est implicite. Nous devrions probablement expliciter cela dans le texte de cette boîte de dialogue, en fait :
Deuxièmement, vous devriez pouvoir générer des liens d’invitation sans e-mail depuis le même endroit où vous envoyez les invitations, comme mentionné ci-dessus .. cela résout complètement le problème du « mais je ne connais pas leurs adresses e-mail ».
Troisièmement, je pense qu’il est acceptable qu’un site soit « sur invitation uniquement » et que les invitations prennent toutes la forme d’hyperliens accompagnés d’un mot de passe secret. De cette façon, c’est :
quelque chose que vous possédez (par exemple, un lien vers un site)
quelque chose que vous connaissez (par exemple, le mot de passe open sesame)
Et si votre site nécessite des approbations, le mot de passe secret vous permet de les contourner. Si vous n’avez pas d’approbations, vous ne pouvez pas entrer sans le mot de passe secret…
Mon principal problème est que nous n’intégrons pas les fonctionnalités existantes ici, mais que nous ajoutons plutôt des éléments aléatoires via un paramètre de site obscur. Mais nous pouvons intégrer pour rendre la fonctionnalité d’invitation encore meilleure, plutôt que de la laisser comme un paramètre de site étrange et autonome.
.. cela résout complètement le problème du « mais je ne connais pas leurs adresses e-mail 
».