Je suis conscient de Discourse Patreon. Bien que ma question concerne Patreon, le « plugin Patreon » n’est pas la réponse que je cherche.
Existe-t-il une bonne méthode pour étendre une classe Ruby afin de spécifier une liste de contrôle d’accès via le code ?
Par exemple : je veux m’assurer que seuls les membres Patreon peuvent publier dans un certain forum ; que seules les personnes d’un certain niveau de confiance peuvent répondre, etc. … mais je ne veux pas cela sous forme de cases à cocher dans une interface graphique. Je veux pouvoir étendre une classe en Ruby et, via le code, spécifier la liste de contrôle d’accès.
Est-ce quelque chose de facile ou de difficile à réaliser dans Discourse ?
Vous pouvez faire tout ce que vous voulez dans un plugin.
Je ne vous recommande pas de gérer les listes de contrôle d’accès (ACL) dans le code. Bien sûr, vous pouvez modifier les comportements et les règles, mais le contrôle d’accès doit être aussi transparent et intuitif que possible pour l’administrateur, n’est-ce pas ? De plus, il y aura des moments où vous devrez apporter des modifications en urgence. Vous ne voulez pas dépendre d’une version de code pour cela !
Essayez de bien comprendre le modèle existant et voyez si vous pouvez obtenir ce dont vous avez besoin sans modifier le code. La sécurité est un élément très important mais délicat, et tant que vous utilisez le cadre existant, l’équipe de Discourse vous soutiendra. Si vous modifiez les choses, vous prenez plus de risques et vous êtes seul responsable.
Gardez également à l’esprit que les modifications de votre plugin doivent être robustes face à l’évolution du cœur du système. Les remplacements doivent être écrits de manière à ce qu’ils continuent de fonctionner même lorsque le code original évolue. C’est un équilibre délicat qui représente une charge de maintenance. Ne pas pouvoir mettre à jour votre instance parce que votre plugin casserait constitue en soi un risque de sécurité.
En fin de compte, les plugins sont particulièrement appropriés pour des modifications superficielles et inoffensives, mais les appliquer à la couche de sécurité ne devrait se faire qu’après une réflexion sérieuse. Il existe cependant des exceptions, comme les plugins OAuth qui fonctionnent avec des fonctionnalités de plateforme permettant d’intégrer facilement de nouveaux fournisseurs.
Ceci dit, bonne chance !
1 « J'aime »