Existe-t-il un moyen de limiter l’accès à la connexion d’un forum à un rôle spécifique, comme les modérateurs ou les administrateurs ?
Contexte : Je migre un forum plus important et, bien que l’URL de ce forum ne soit pas connue du public, je souhaite restreindre la connexion aux seuls modérateurs et administrateurs pendant que nous testons tout après la migration et nous préparons pour le transfert final.
Je pensais avoir vu une option dans le passé, mais je ne parviens pas à la retrouver.
Vous pouvez configurer le forum pour qu’il soit sur invitation uniquement jusqu’à ce qu’il soit opérationnel. Ensuite, vous pourrez le modifier pour accepter les inscriptions publiques une fois prêt. Dans votre Tableau de bord, allez dans Connexion et cochez les cases pour le configurer comme vous le souhaitez. Une fois prêt, revenez-y et apportez les modifications nécessaires.
Vous souhaitez probablement suspendre tous les utilisateurs afin qu’ils ne reçoivent pas d’e-mails, ce qui les empêcherait de se connecter même s’ils tombent par hasard sur le site.
Si cela ne suffit pas, vous pouvez modifier la configuration nginx dans le conteneur pour exiger une authentification basique afin d’accéder au site.
Je n’étais vraiment pas au courant que Discourse ne disposait pas vraiment de fonctionnalités basées sur les rôles. Je ne l’avais utilisé que dans des projets où cela n’était pas un problème. Je pensais qu’il serait possible de limiter la connexion par ce biais.
@JimPas, comme @Stephen l’a justement dit, cela ne fonctionnera pas pour les utilisateurs importés.
Le changement de nom DNS sera en place pendant cette période, car l’ancien forum restera actif pendant ce temps, mais comme je l’ai dit initialement, je voulais une protection supplémentaire.
Il semble que l’authentification HTTP de base soit le seul moyen d’ajouter une protection supplémentaire et d’empêcher les utilisateurs de se connecter. Je dois vérifier comment cela fonctionne.
Pas tout à fait. Vous avez toujours le bon vieux recours consistant à supprimer l’enregistrement DNS public et à utiliser une entrée de fichier hosts pendant les périodes nécessaires. Cela cassera Let’s Encrypt si vous reconstruisez pendant que le DNS public est absent, mais sinon cela fonctionne. Les utilisateurs devront connaître le nouveau nom DNS ET l’adresse IP pour y accéder.
Désactiver les comptes est une option, mais il existe également la possibilité de désactiver tous les e-mails dans /admin, ce qui est probablement prudent.
En y réfléchissant, vous pouvez également contrôler l’accès en ajoutant une couche supplémentaire en mettant en œuvre votre propre IdM/SSO. Plus de travail, mais des retombées potentiellement énormes dans d’autres domaines à long terme. Tout dépend de ce avec quoi vous vous sentez à l’aise.
Merci d’avoir mentionné les alternatives, @Stephen.
Je pense que l’authentification de base serait la méthode la plus simple. L’utilisation des fichiers hosts locaux est un peu fastidieuse pour les membres du personnel ou les modérateurs moins avancés sur le plan technique, et l’IdM/SSO est certainement trop compliqué pour la courte période de temps espérée nécessaire pour poser les bases de la migration finale. De plus, nous ne sommes pas très sécurisés là-bas, donc nous risquons de ne pas du tout sécuriser cela non plus.
Juste pour mettre à jour ce sujet, je crois que nous avons maintenant un mode « lecture seule pour le personnel ». Je ne suis pas sûr à 100% de savoir comment l’activer cependant. Je ne trouve pas de bouton dans l’interface utilisateur, à part le « lecture seule pour tout le monde » habituel.
Je vais explorer.
Nous avons maintenant des instructions dans un guide :
Je ne trouve pas de bouton dans l’interface utilisateur, à part le « lecture seule pour tout le monde » habituel. 