Bonjour !
Je souhaite modifier les autorisations des groupes d’utilisateurs, par exemple :
Groupe Administrateur - toutes les autorisations
Co-administrateur - peut tout faire sauf ouvrir certaines sections du panneau d’administration
Comment procéder ? Merci !
Ce n’est pas possible par défaut, car les administrateurs ont un accès illimité à toutes les sections du forum. Selon le type de permissions que vous souhaitez révoquer, peut-être que les rétrograder au rang de modérateur pourrait être utile ?
Le modérateur ne peut pas créer de catégories, et je le souhaite
Les modérateurs peuvent créer des catégories si vous activez le paramètre moderators_create_categories dans votre administration Discourse.
Où puis-je le trouver ? J’ai parcouru toutes les catégories dans le panneau d’administration et je n’ai rien vu que je puisse attribuer aux modérateurs.
*Existe-t-il quelque chose comme moderators_create_themes ?
Accédez à Admin > Paramètres
Ensuite, recherchez le mot-clé moderators_create_categories
Votre Discourse est-il à jour ?
Ce que vous demandez, c’est : « Existe-t-il quelque chose comme ‘les modérateurs peuvent faire planter tout le site en créant un thème cassé’ ? ». Je suis presque certain que la réponse sera « Non ».
Vous pourriez installer un thème distant hébergé sur GitHub qu’un modérateur pourrait modifier, mais un administrateur devrait toujours récupérer les modifications.
Vous ne savez pas qui va bidouiller les thèmes, comment pouvez-vous faire une telle affirmation ?
J’ai posé cette question parce qu’il n’existe pas de groupes avec des règles personnalisées comme indiqué ci-dessus.
Mon point est que si vous faites suffisamment confiance à quelqu’un pour changer les thèmes, vous pouvez en faire un administrateur.
Si vous souhaitez permettre à des non-administrateurs de modifier les thèmes ou de changer ce qu’un modérateur peut faire, vous aurez besoin d’un plugin personnalisé.
Pas dans mon scénario actuel. Nous disposons d’équipes UX et Design qui ne sont responsables que de ce domaine, l’accès aux thèmes serait donc suffisant.
Nous avons le même cas d’usage. Nous faisons appel à des prestataires externes (webdesigners) auxquels nous souhaitons accorder un accès à cette fonctionnalité. Un administrateur complet aurait accès à tout, y compris aux discussions de gestion privées, ce qui n’est pas souhaitable.
Il serait idéal de disposer d’un flux de travail permettant aux webdesigners de proposer ou de tester des modifications sans avoir un accès administrateur complet.
Bonjour @Joaquin_Menchacha,
Merci pour votre message et pour ce rappel sur ce sujet.
Nous souhaitons également (prévoyons) d’affiner certains contrôles d’administration à l’avenir.
Par exemple, nous sommes intéressés par un plugin (un jour) qui sera configuré avec des variables dans le fichier de conteneur yml et qui restreindra certaines actions d’administration (comme le téléchargement de la sauvegarde complète du site) à certains utilisateurs uniquement (identifiants d’utilisateur).
Cette idée de plugin est « sur ma table de travail » et, dès que j’aurai l’occasion, je m’y pencherai plus en détail. Pour l’instant, je n’ai même pas encore fait le premier pas consistant à examiner le code et à évaluer la faisabilité de cette idée.
Quelqu’un a-t-il trouvé une solution ici ?
J’ai le même cas d’usage où je souhaite accorder à certains de mes collaborateurs l’accès au thème et aux annonces internes.
La solution la plus simple est de faire confiance aux personnes et de leur attribuer le rôle d’administrateur ou de modérateur. Si vous ne leur faites pas confiance pour avoir un contrôle total, mais que vous souhaitez leur accorder un accès supplémentaire, vous aurez alors besoin d’un plugin.
Ce n’est pas que je ne leur fais pas confiance. Mais en ce qui concerne notre modèle de menace, cela crée une surface d’attaque supplémentaire. Et si l’utilisateur spécifique était compromis en raison d’un manque de sécurité de son côté ? Il y a beaucoup de variables en jeu.
Nous explorerons donc l’option du plugin.
D’accord, Discourse a besoin de contrôles supplémentaires pour la personnalisation. Comme d’autres l’ont mentionné, cela pourrait inclure la possibilité d’engager des prestataires externes pour utiliser des fonctions de niveau supérieur tout en protégeant les informations des membres.
La modération par groupe est correcte, mais il arrive que l’on souhaite certaines fonctions avancées d’un modérateur complet sans en avoir toutes les fonctionnalités.
Un plugin pourrait en effet s’avérer utile. Mais tout comme le plugin « Merge User » a été intégré au cœur du système, il faudrait également intégrer des fonctionnalités de modération/administration personnalisées plus puissantes afin de permettre plus de types de personnel.
Je rejoins les autres contributeurs ici : le modèle de contrôle d’accès gagnerait à être amélioré avec une couche supplémentaire de granularité RBAC (contrôle d’accès basé sur les rôles) permettant de spécifier précisément ce que les staff et admin peuvent accéder (pour certaines fonctions, pas toutes).
Par exemple, un site pourrait souhaiter ajouter davantage d’administrateurs, mais préférer leur accorder un ensemble restreint de privilèges RBAC ; par exemple, autoriser ou non le téléchargement de la sauvegarde complète du site ou l’accès à certains fichiers de journaux d’actions du personnel. De plus, un site pourrait souhaiter s’assurer que certains membres du personnel n’ont pas les permissions RBAC pour consulter les actions du personnel effectuées par les administrateurs ou les développeurs, ou simplement certaines actions considérées comme plus « privées ».
Tous les experts en cybersécurité apprennent (et le savent par expérience directe) que la plus grande menace pour toute organisation est l’« employé mécontent » et non les pirates ou attaquants externes. Il ne fait aucun doute quant à ce risque fondamental en sécurité informatique, et c’est une connaissance bien établie pour les professionnels de la sécurité informatique formés ou expérimentés. Par conséquent, rejeter la menace intérieure en disant « faites simplement confiance à votre administrateur » ou « vous devez faire confiance à votre personnel » n’est pas une solution technique pour les professionnels de l’informatique. Même le personnel le plus digne de confiance, loyal depuis de nombreuses années, peut commencer à rencontrer des problèmes personnels susceptibles de le transformer en « employé mécontent ». De plus, ce sont les membres du personnel les plus privilégiés qui commettent le plus d’erreurs ; et nous savons tous que les erreurs bien intentionnées du personnel ou des administrateurs provoquent généralement plus d’arrêts de service que n’importe quel pirate, en général.
Il y a quelque temps, j’ai envisagé de modifier la classe Guardian de Discourse pour notre site, mais après un examen plus approfondi de cette classe, il ne m’a pas semblé évident qu’il existait une « solution rapide » me permettant d’écrire un minimum de code de patch (monkey patch) pour améliorer le RBAC de Discourse. Étant naturellement paresseux et préférant créer des solutions simples chaque fois que possible, j’ai mis cette idée de côté pour me consacrer à d’autres projets de « clients bien rémunérés ».
Par la suite, j’ai envisagé de descendre d’un niveau dans le code et de transférer certaines des fonctions staff et admin vers developer, mais cette approche nécessitait trop de patches (monkey patches), ce qui, à l’époque, ne me semblait pas être une bonne idée. Après tout, si nous pouvons accomplir quelque chose avec un seul patch plutôt qu’avec dix, il est évident qu’un seul patch est préférable.
Je n’ai pas encore eu le temps ni une « exigence urgente » d’approfondir cette partie du cœur de Discourse pour déterminer s’il existe une extension de plugin RBAC « facile » que je pourrais écrire via un plugin « relativement simple ».
Honnêtement, je pense que le problème est que je ne suis pas encore un super développeur Ruby et que, pour l’essentiel, je me considère davantage comme un « aspirant » codeur Ruby, LOL. Je suis convaincu qu’il existe, plus que probablement, une solution de plugin RBAC simple quelque part, mais personnellement, je ne l’ai pas encore trouvée. Peut-être qu’une personne Ruby beaucoup plus expérimentée pourra examiner rapidement le code et voir comment aborder ce problème.
Mon idée serait d’ajouter de nouveaux paramètres booléens au site qui limiteraient ou accorderaient des permissions RBAC spécifiques en fonction du rôle, puis d’intégrer ces booléens dans la partie appropriée du code via un patch (monkey patch) dans un plugin. Cependant, comme je l’ai mentionné, je préférerais patcher un seul fichier et non « plusieurs », afin que ce soit propre, simple et facile à maintenir.
Quand j’aurai le temps, j’étudierai plus en profondeur cette amélioration du RBAC, car elle est certainement intéressante.
Bonjour @jrgong,
Ce n’est pas difficile à réaliser via un plugin, comme vous le savez probablement bien.
En gros, vous pourriez créer une liste de membres du personnel (par e-mail, nom d’utilisateur, etc.) en tant que paramètre global, de manière similaire à la façon dont Discourse définit les développeurs par adresse e-mail.
Ensuite, vous pourriez utiliser ce GlobalSettting dans certaines patches pour autoriser les deux cas d’usage qui vous intéressent.
Le premier de vos cas d’usage : personnaliser les thèmes en tant que membre du personnel, est relativement simple à implémenter via un monkey patch du cœur, je pense.
Pour le deuxième cas d’usage, avec peu de travail, vous pourriez forker ce plugin et redessiner la contrainte d’accès aux routes dans ce plugin (et tout autre changement nécessaire) :
Puisque la contrainte pour le plugin de publicité est intégrée au plugin, il est judicieux de modifier ce code pour permettre à votre personnel « autorisé » d’accéder aux parties de ce plugin que vous souhaitez autoriser, en fonction de votre propre RBAC.
Autrement dit, les deux exigences que vous souhaitez sont réalisables si vous êtes prêt à écrire le code ; ou bien, bien sûr, vous pouvez demander à l’un des développeurs de plugins Discourse experts de vous aider dans Marketplace.
Merci @neounix, j’apprécie vraiment ton retour ! Je vais demander à un développeur de s’en charger.
edit : Y a-t-il vraiment aucune autre solution que de faire un fork du plugin ?
Et qu’en est-il de l’accès au plugin Babble Chat ? Cela nécessiterait-il aussi un fork ?
Nous parlons de logiciel.
Il existe toujours de nombreuses façons de faire les choses.
Je vous ai donné mes recommandations.
