Nous avons eu un grave problème de sécurité avec le système d’invitation. Je suppose qu’il est facilement reproductible. Notre site est sur invitation uniquement. De plus, nous avons coché “doit approuver les utilisateurs” dans les paramètres.
Un de nos employés a émis une invitation avec un nombre d’utilisations maximum supérieur à 1, donc non restreint à un e-mail en particulier (exemple ci-dessous).
Ce lien d’invitation a circulé, et des personnes ont pu s’y enregistrer. Pourtant, nous nous attendions à ce que lorsque “doit approuver les utilisateurs” est coché dans les paramètres, le personnel doive approuver toute personne utilisant ces invitations “sans restriction d’e-mail”. Au lieu de cela, ils ont tous été admis automatiquement, quiconque possédait ce lien. Le lien peut donc être utilisé par n’importe qui et nous ne pouvons pas vérifier qui y accède. Nous devons être en mesure de “vérifier les antécédents”, en utilisant la combinaison de l’e-mail, du nom et d’autres champs que nous avons ajoutés, qui sont des champs obligatoires que nous demandons pour approbation (après vérification).
Cela a créé un grave problème car une personne d’une organisation étrangère strictement interdite a obtenu ce lien et s’est enregistrée. J’ai dû supprimer ce compte immédiatement. C’est une faille sérieuse pour nous.
Je trouve donc que l’option “doit approuver les utilisateurs” est dangereusement trompeuse. Actuellement, cette option est inutile si notre instance est sur invitation uniquement.
Existe-t-il un moyen pour que le personnel puisse approuver quelqu’un utilisant le lien d’invitation qui n’a pas été restreint par e-mail ? Cela semblerait être un moyen logique d’activer “doit approuver les utilisateurs” lorsque le site est sur invitation uniquement.
Je peux reproduire le problème, lorsqu’une invitation en masse est générée, les utilisateurs qui s’inscrivent avec ce lien sont automatiquement immunisés contre le paramètre “les utilisateurs doivent être approuvés”.
Avez-vous vu quelque chose dans la documentation qui vous a amené à croire que les invitations qui n’étaient pas liées à un e-mail ajoutaient l’étape d’approbation @Wall-E ?
La chose clé ici est qu’un membre du personnel a émis l’invitation. Discourse traite cela comme une approbation implicite des utilisateurs qui utilisent l’invitation.
Si un membre du personnel a généré l’invitation, l’utilisateur qui l’a utilisée serait ajouté à la file d’attente pour approbation par le personnel.
donc si un compte utilisateur non-employé est utilisé pour créer une invitation, alors les inscriptions via cette invitation seraient mises en attente de révision ? Si c’est le cas, c’est un comportement tout à fait acceptable et @Wall-E vous pourriez utiliser un compte régulier factice pour générer l’invitation comme solution de contournement.
Je pense qu’il devrait au moins y avoir un avertissement pour les utilisateurs du personnel, et ce serait formidable s’ils pouvaient choisir la manière dont les nouveaux membres seront traités. Utiliser un second utilisateur, « normal », serait une solution de contournement laide.
En parcourant ce sujet et les sujets précédents, je constate que le fonctionnement actuel est « par conception », mais qu’il ne reflète pas les nouveaux changements apportés au système d’invitation. Il est devenu beaucoup plus facile de créer des liens d’invitation qui peuvent être utilisés par des personnes inconnues. Les liens d’invitation peuvent désormais également être créés dangereusement par le personnel qui ajoute des invités à des groupes qui peuvent avoir accès à des catégories sécurisées sur le site.
@Wall-E Je suis curieux de comprendre comment vos liens d’invitation tombent entre les mains de personnes qui ne devraient pas être autorisées à accéder à votre site. On suppose que le personnel de votre site saura faire attention à ne pas créer de liens d’invitation qui peuvent être utilisés par n’importe qui et à ne pas les partager publiquement ou dans des contextes où les mauvaises personnes pourront les utiliser. Dans une certaine mesure, le problème que vous rencontrez est un problème de formation du personnel. N’hésitez pas à m’envoyer un message privé si votre réponse contient des détails sensibles.
S’il existe actuellement des liens d’invitation compromis, vous pouvez les supprimer et en créer de nouveaux, et les partager plus prudemment à l’avenir. En tant qu’administrateur, vous pouvez également toujours consulter la page des invitations pour voir qui a utilisé ses invitations. Si vous avez du personnel en qui vous n’avez pas confiance, vous pouvez abaisser ses privilèges à TL4, qui possède des privilèges de modérateur.
Je vois trois actions possibles :
Ne rien faire. Le système d’invitation fonctionne comme prévu, le personnel doit simplement faire attention avec ses liens d’invitation. Si nous choisissons cette voie, suggérons de modifier la description du paramètre d’administration doit approuver les utilisateurs pour qu’il soit parfaitement clair que les liens d’invitation créés par les administrateurs contournent ce paramètre.
Le personnel doit approuver tous les nouveaux comptes d’utilisateurs avant qu’ils ne soient autorisés à accéder au site. Remarque : les invitations créées par le personnel contournent ce paramètre et ne nécessitent pas d’approbation.
Faire (1) mais aussi ajouter une étape d’avertissement supplémentaire « êtes-vous sûr » lorsque les administrateurs créent un lien d’invitation qui peut être utilisé pour obtenir immédiatement un accès au site. Uniquement sur les sites où l’approbation est requise.
Modifier le comportement afin que les liens d’invitation créés par les administrateurs respectent le paramètre d’approbation requis, tout comme les invitations des non-administrateurs.
Je suis d’accord avec l’OP sur le fait que le comportement actuel est trompeur et peut entraîner des problèmes sur les sites lorsque l’approbation est requise. Les sites avec ce paramètre activé sont plus prudents et ont besoin de ce niveau de contrôle supplémentaire et paranoïaque sur qui peut y accéder.
Ma recommandation serait donc de choisir la porte numéro trois : faire en sorte que tous les liens d’invitation fonctionnent de la même manière et respectent le paramètre doit approuver les utilisateurs.
Je ne pense pas qu’il s’agisse d’un bug, cependant. Cela fonctionne comme prévu. Reclassification en demande de fonctionnalité.
Je suis également fortement en faveur de l’option 3. Je construis une communauté où les gens peuvent réfléchir plus profondément aux émotions et je pense qu’ajouter ce niveau supplémentaire de contrôle sur les liens d’invitation anonymes (car ils ne sont pas liés à une adresse e-mail ou à une identité) pourrait me rassurer sur le fait que seules les personnes que je souhaite voir rejoindre le feront.
Je suppose que je pourrais m’assurer d’utiliser l’e-mail d’invitation au lieu du lien d’invitation anonyme, mais le lien facilite grandement le partage sur Whatsapp ou d’autres plateformes de communication.
Je suis donc également favorable à ce que les liens d’invitation anonymes respectent le paramètre « approuver les utilisateurs ».
De plus, je pense que si le #3 se produit, le système d’invitation pourra fonctionner presque comme un système de candidature pour les forums sur invitation uniquement. Actuellement, je ne suis pas sûr de la manière dont je pourrais faire postuler des personnes pour devenir membres sans avoir un Google Form séparé ou autre. Cela pourrait rationaliser les choses, où les champs utilisateur personnalisés pourraient être le formulaire de candidature — ce que je pense que @Wall-E essaie de faire.
Ce n’est pas ce dont parle mon sujet. Je parle du fait que must_approve_users n’a aucun effet sur une instance par invitation uniquement. L’activer devrait avoir un effet différent que de le désactiver. Sinon, il devrait être documenté que ce comportement ne s’applique pas aux instances par invitation uniquement. Si je l’ai manqué dans la documentation, alors c’est effectivement la responsabilité de notre personnel. Mais si ce n’est pas le cas, alors cette fonctionnalité est trompeuse et devrait être corrigée, ou du moins documentée), car elle a induit en erreur tout notre personnel.
Absolument. J’aurais pu manquer cela dans la documentation, si cela avait été documenté, alors ce serait ma responsabilité d’avoir induit mon personnel en erreur, et un avertissement ne fera pas de mal, car les gens/le personnel peuvent oublier.
Je vais citer les responsables qui peuvent nous fermer en raison de cet aspect, qui est considéré comme un problème de sécurité dans notre organisation : « Si ce système peut permettre à quelqu’un d’une organisation non autorisée d’entrer, vous devez supposer que cela finira par arriver, quelle que soit votre diligence ». C’est exactement ce qui s’est passé. Cette « fonctionnalité » (je dirais plutôt une non-fonctionnalité car le « must_approve_user » n’a aucun effet dans le cas d’une invitation uniquement) a été activée, nous avons émis l’invitation sans restriction aux personnes mêmes que nous voulions inviter, et évidemment, l’une de ces personnes a partagé ce lien d’invitation sans restriction avec une autre organisation.
Avec ceci, je réponds également à @tobiaseigen
Nous avons des réunions, des conférences, avec parfois des centaines de personnes d’organisations autorisées qui sont autorisées à rejoindre notre forum. Mais certaines d’entre elles proviennent parfois d’autres organisations qui ne sont pas autorisées à rejoindre notre forum (en raison de politiques générales indépendantes de notre volonté).
Ce lien d’invitation s’est « échappé », même avec la diligence du personnel, car nous ne pouvons pas contrôler ce que les personnes « implicitement autorisées » avec ce lien feront ; par définition, ce lien est « sans restriction », donc elles peuvent le transmettre à qui elles veulent. Je ne peux pas blâmer mon personnel pour cela, car si vous dites que c’est « par conception » qu’il y a une approbation implicite, cela signifie que ce lien d’invitation sans restriction peut aller n’importe où, donc il finira par y aller. C’est exactement de quoi parlaient nos responsables du département informatique, pour de bonnes raisons. Nous le savions, et c’est pourquoi nous avons activé le « must_approve_users » pour agir comme cette couche de sécurité que nous pensions qu’elle était.
Je vois qu’il y a une question de savoir s’il s’agit d’une fonctionnalité ou d’un bug. Je ne suis pas un programmeur professionnel, c’est à vous de décider (je suis astrophysicien). Je vous signale simplement un « problème » sérieux qu’il nous a causé, en espérant qu’il pourra être résolu afin que nous puissions continuer à utiliser cette merveilleuse plateforme.
Je suis entièrement favorable à l’option 3, tout comme notre centre de recherche et le personnel de mon forum. Jusqu’à nouvel ordre, le personnel a reçu l’instruction de ne pas utiliser l’invitation sans restriction. Cela ajoute une charge supplémentaire car ils doivent maintenant ajouter toutes les adresses e-mail individuelles des personnes que nous voulons inviter (et lors d’une conférence, cela représente plus de centaines de participants…). Le faire à chaque réunion, événement, etc… ajoutera une forte viscosité à notre croissance, et je peux prévoir que certains membres du personnel partiront en raison de la charge de travail supplémentaire (la plupart sont des bénévoles, et tous surchargés par leurs autres fonctions).
Est-il possible de supposer que si l’option 3 est retenue, il y aura une option pour reproduire le comportement existant ?
Le site de formation que nous avons mis en place aurait été beaucoup plus difficile à réaliser sans la possibilité de contourner les approbations pour les groupes qui ont été invités en masse.
N’oubliez pas que les invitations en masse sont également une option ici. Si votre événement génère un fichier CSV des participants, vous pouvez l’utiliser pour inviter tout le monde directement.
Sinon, vous pouvez également partager une URL vers un formulaire Web pour remplir un fichier CSV et valider les utilisateurs avant d’envoyer l’invitation en masse.
Malheureusement, nos événements typiques ne nous donnent pas accès à cela. Ces listes de contacts sont considérées comme des informations personnelles identifiables (PII) par l’organisation hôte qui organise la conférence/la réunion. Même si nous avions accès, nous n’avons tout simplement pas la bande passante pour utiliser cette fonctionnalité. Nous devrions entrer en contact avec un responsable, qui est toujours surchargé (même si nous sommes autorisés à avoir accès à l’information), donc encore une fois, forte viscosité, le temps que nous obtenions les liens d’invitation, l’événement est terminé, l’élan est perdu (par notre personnel et par nos invités potentiels).
Noté. Cela pourrait être une solution de contournement. Mais cela représente une charge de travail supplémentaire pour notre personnel, qui n’a pas beaucoup de bande passante pour traiter cette étape supplémentaire. Donc, ce n’est pas idéal.
Je vois que cela vous a causé des problèmes, ainsi qu’à votre communauté, et j’en suis désolé !
À l’avenir, vous saurez comment cela fonctionne, vous pourrez donc vous assurer que vous-même, ainsi que les autres administrateurs et modérateurs, utiliserez le système d’invitation judicieusement !
La question fonctionnalité vs bug concerne la priorisation : nous essayons de corriger les bugs rapidement, surtout s’il s’agit de bugs de sécurité ! Mais dans ce cas, la fonctionnalité est la même que depuis des années et elle est conçue ainsi. Je pense que nous devrions la changer, mais ce n’est pas une chose à régler immédiatement.
Nous allons laisser cela mûrir pour que d’autres puissent donner leur avis afin que nous puissions décider de la direction à prendre.
Cela peut être un changement beaucoup plus complexe en fonction de la manière dont le gardien est impliqué dans les différents éléments de ce processus, mais une autre option, qui dépendrait également de 3, est :
Ajoutez une propriété booléenne aux invitations elles-mêmes pour contourner l’approbation de l’utilisateur. Cette propriété serait désactivée par défaut et ne serait exposée dans l’interface utilisateur de création d’invitation que lorsque must_approve_users est activé.
Edit : En regardant à nouveau le code auquel David a fait référence, je suppose que le gardien n’est pas du tout impliqué dans la décision de savoir si un utilisateur invité doit être approuvé. Il semble que cette partie serait un remplacement simple de invite.invited_by.staff? par quelque chose comme invite.bypass_approval?
Je comprends tout à fait vos contraintes de priorisation. Je suppose que notre instance se trouve dans une situation peu commune, car toutes les instances Discourse que je connais proviennent d’organisations qui n’ont pas les politiques de sécurité strictes auxquelles nous devons nous conformer. Par exemple, l’inscription sur invitation uniquement était une contrainte imposée par notre organisation, notre instance ne pourrait pas exister avec l’auto-inscription. Avec l’auto-inscription, ce serait plus facile, nous n’aurions pas besoin d’utiliser les invitations sans restriction qui peuvent se “perdre”.
