Désactivation de l'exigence d'e-mail d'activation pour les utilisateurs invités

Dev
1

Salut à tous, j’ai un cas d’usage qui n’est pas encore très bien pris en charge : je dois désactiver l’e-mail d’activation pour les utilisateurs invités — y compris les utilisateurs invités via un lien.

Après avoir créé le sujet ci-dessus, cela a été implémenté, mais uniquement pour les utilisateurs invités par e-mail.

Mon instance Discourse est réservée aux invités et j’envoie effectivement des liens d’invitation par e-mail, mais pas via les e-mails intégrés de Discourse. Je génère les liens d’invitation avec une requête POST vers /invites/link et les stocke dans une base de données externe, puis j’envoie ces liens aux utilisateurs. Ainsi, lorsque les utilisateurs cliquent sur le lien, ils ont déjà vérifié leur adresse e-mail, mais on leur demande de le faire à nouveau.

Je réalise que mon cas d’usage n’est pas particulièrement courant, alors j’ai pensé essayer de créer un plugin simple pour modifier les parties nécessaires de Discourse afin que cela fonctionne comme je le souhaite.

J’ai mis en place une structure de base et ajouté un paramètre du site (no_activation_enabled). Après avoir parcouru le dépôt principal, je pense que c’est peut-être ce fichier qu’il faut modifier :

Je ne suis pas totalement sûr, mais je pense qu’en modifiant conditionnellement (si SiteSetting.no_activation_enabled est activé et si l’utilisateur a été invité par un membre du personnel, peut-être via invite.invited_by.staff ?) la valeur de active à true dans user.attributes, cela pourrait fonctionner :

    user.attributes = {
      email: invite.email,
      username: available_username,
      name: name || available_username,
      active: false,
      trust_level: SiteSetting.default_invitee_trust_level,
      ip_address: ip_address,
      registration_ip_address: ip_address
    }

Mais comment puis-je modifier cela depuis un plugin ? Est-ce même dans le champ d’action des plugins ? Ou peuvent-ils uniquement ajouter des fonctionnalités, sans les modifier ? Ou dois-je remplacer entièrement le fichier invite_redeemer.rb ?

J’ai terminé le tutoriel sur la création de plugins, ainsi que ce guide, mais après des heures à essayer de fouiller dans la base de code, y compris d’autres plugins, j’ai l’impression de me frapper la tête contre un mur… Donc si quelqu’un a des pistes à me proposer, je lui serais extrêmement reconnaissant !

2

Si vous gérez cela depuis un site externe, pourquoi ne pas lui faire gérer l’authentification unique (SSO) et simplement transmettre la vérification dans le payload ?

3

Bonjour Stephen, merci pour ton retour.

Je ne gère pas les comptes utilisateurs sur un site externe. J’utilise un système maître combinant Airtable, Zapier et des GCFs pour connecter plusieurs services (ESP, etc.), mais Discourse reste la principale base de données utilisateurs. Je ne souhaite simplement pas utiliser le formulaire d’inscription standard de Discourse, car il n’est pas optimal pour la conversion et ne peut pas être intégré, par exemple, dans des articles de blog. En réalité, Discourse agit comme fournisseur d’authentification unique (SSO) pour le site de contenu basé sur Jekyll : il envoie des requêtes fetch pour vérifier si un utilisateur est connecté sur Discourse et adapte les pages de contenu en conséquence.

4

Salut, bienvenue :slight_smile:

Comme @Stephen, je ne suis pas tout à fait sûr que ce soit le bon outil, mais je fais confiance au fait que tu aies bien réfléchi à la question.

Je l’éviterais à tout prix. Il existe presque toujours une autre solution, même si cela implique de patcher une classe de manière dynamique (monkey patching). Pour en savoir plus sur le monkey patching dans Discourse, consulte : Override existing Discourse methods in plugins.

Dans ce cas, il semble qu’il y ait déjà du code dans la méthode sur laquelle tu te concentres qui fait ce que tu recherches : discourse/app/models/invite_redeemer.rb at main · discourse/discourse · GitHub

Le problème est que les invitations que tu as générées n’ont pas le bon emailed_status_type, donc la condition n’est pas satisfaite. Je pense que la solution consiste à générer des invitations différentes dès le départ. C’est là que je me concentrerais.

5

Cela revient essentiellement à réintroduire une fonctionnalité retirée du cœur du système car elle était trop dangereuse : si vous gérez mal ces jetons d’invitation, quiconque les vole (avant que le destinataire prévu ne les utilise) pourrait se connecter au forum en tant que destinataire. Je recommande vivement de ne pas utiliser ce type d’invitation pour les comptes de modérateurs ou d’administrateurs.

C’est pourquoi le code pour gérer cela est déjà présent, mais vous devrez effectuer quelques ajustements personnalisés pour y accéder.