Explication graphique détaillée de la conception de la base de données de gestion des droits des utilisateurs RBAC dans thinkphp

RBAC (Role-Based Access Control, Access Control basé sur les rôles) signifie que les utilisateurs sont associés à des autorisations via des rôles. En termes simples, un utilisateur a plusieurs rôles et chaque rôle dispose de plusieurs autorisations. De cette manière, le modèle d'autorisation de "user-role-permission" est construit. Dans ce modèle, il existe généralement une relation plusieurs-à-plusieurs entre les utilisateurs et les rôles, ainsi qu'entre les rôles et les autorisations. (Comme indiqué ci-dessous)

Quel est le rôle ? Il peut être compris comme un ensemble d'un certain nombre d'autorisations et un support d'autorisations. Par exemple : dans un système de forum, « super administrateur » et « modérateur » sont des rôles. Les modérateurs peuvent gérer les publications du forum, gérer les utilisateurs du forum, etc. Ce sont des autorisations. Pour accorder ces autorisations à un utilisateur, vous n'avez pas besoin d'accorder des autorisations directement à l'utilisateur. Vous pouvez attribuer à l'utilisateur le rôle de « modérateur ».

Lorsque le nombre d'utilisateurs est très important, il est très fastidieux d'autoriser (accorder des rôles) à chaque utilisateur du système un par un. À ce stade, les utilisateurs doivent être regroupés , et chaque groupe d'utilisateurs compte plusieurs utilisateurs. En plus d'autoriser les utilisateurs, vous pouvez également autoriser des groupes d'utilisateurs. De cette manière, toutes les autorisations dont dispose un utilisateur sont la somme des autorisations détenues par l'utilisateur personnellement et des autorisations détenues par le groupe d'utilisateurs auquel l'utilisateur appartient. (L'image ci-dessous montre la relation entre les groupes d'utilisateurs, les utilisateurs et les rôles)

Dans le système d'application, les performances des autorisations Quoi ? Le fonctionnement des modules de fonction, la suppression et la modification des fichiers téléchargés, l'accès aux menus, et même le contrôle de la visibilité d'un certain bouton et d'une certaine image sur la page sont tous. Peut relever de l'autorité. Certaines conceptions d'autorisation traiteront les opérations fonctionnelles comme une catégorie, et les fichiers, menus, éléments de page, etc. comme une autre catégorie, formant ainsi un modèle d'autorisation « rôle-permission-ressource utilisateur ». Lors de la modélisation de tables de données, les opérations fonctionnelles et les ressources peuvent être gérées de manière unifiée, c'est-à-dire qu'elles sont directement associées à la table d'autorisations, ce qui peut être plus pratique et évolutif. (Voir l'image ci-dessous)

Veuillez noter qu'il y a une colonne "Type d'autorisation" dans le tableau des autorisations, nous en fonction de sa valeur Pour distinguer le type d'autorisation, tel que "MENU" signifie l'autorisation d'accès au menu, "OPERATION" signifie l'autorisation de fonctionnement du module fonction, "FILE" signifie l'autorisation de modification de le fichier, "ELEMENT" désigne l'autorisation de l'élément de page Contrôle de visibilité, etc.

Il y a deux avantages à cette conception. Premièrement, il n'est pas nécessaire de distinguer quelles sont les opérations d'autorisation et lesquelles sont les ressources (en fait, il n'est parfois pas facile de distinguer, comme le menu, doit-il être compris comme une ressource ou une autorisation de module fonction ?). Deuxièmement, c'est pratique pour l'expansion. Lorsque le système souhaite contrôler les autorisations sur de nouvelles choses, il me suffit de créer une nouvelle table d'association "Permission XX Association Table" et de déterminer le type d'autorisation de ces autorisations String .

Il convient de noter ici qu'il existe une relation un-à-un entre la table d'autorisation et la table d'association de menu d'autorisation, et la table d'association de menu d'autorisation et la table de menu. (Il en va de même pour les fichiers, les autorisations de page, les opérations fonctionnelles, etc.). Autrement dit, chaque fois qu'un menu est ajouté, un enregistrement doit être inséré dans chacune de ces trois tables en même temps. De cette façon, la table d'association du menu d'autorisation n'est pas nécessaire et la table d'autorisation est directement associée à la table de menu. À ce stade, une colonne doit être ajoutée à la table d'autorisation pour enregistrer l'ID du menu. La table transmet le "type d'autorisation". Utilisez cet ID pour distinguer sous quel enregistrement il se trouve.
À ce stade, le schéma de conception complet du modèle étendu du modèle d'autorisation RBAC est le suivant :

À mesure que le système devient de plus en plus grand, afin de faciliter la gestion, des groupes de rôles peuvent être introduits pour classer et gérer les rôles. Contrairement aux groupes d'utilisateurs, les groupes de rôles ne participent pas à l'autorisation. Par exemple : dans le module Gestion des autorisations d'un certain système de réseau électrique, les rôles sont suspendus au bureau de district, et le bureau de district peut être utilisé ici comme groupe de rôles, et il ne participe pas à la distribution des autorisations. . De plus, afin de faciliter la gestion et la recherche de chaque table principale ci-dessus, une structure arborescente peut être utilisée, comme une arborescence de menus, une arborescence de fonctions, etc. Bien entendu, celles-ci n'ont pas besoin de participer à l'attribution des autorisations.

Ce qui précède est développé à partir du modèle RBAC de base, et la conception spécifique doit être ajustée en fonction des besoins de l'activité du projet.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!