Quelle est la meilleure façon de gérer les autorisations pour une application Web - masque de bits ou table de base de données?

Question

Je suis en train d'étudier la meilleure façon de concevoir un système d'autorisations pour un "admin" de l'application web. L'application est susceptible d'avoir de nombreux utilisateurs, dont chacun peut être affecté un certain rôle; certains de ces utilisateurs peuvent être autorisés à effectuer des tâches spécifiques en dehors du rôle.

Je pense à deux manières de concevoir ceci: l'un, avec un "autorisations" de table avec une ligne pour chaque utilisateur, booléens et de colonnes, une pour chaque tâche, que de leur attribuer des autorisations pour effectuer ces tâches. Comme ceci:

ID d'utilisateur Gérer les Utilisateurs Gérer les Produits de Gérer des Promotions gestion des Commandes
1 true true true true
2 faux vrai vrai vrai
3 faux faux faux vrai

Une autre façon j'ai pensé a utiliser un masque de bits pour stocker ces autorisations de l'utilisateur. Cela permettrait de limiter le nombre de tâches qui pourraient être gérés à 31 pour un entier signé 32 bits, mais dans la pratique, nous sommes peu de chances d'avoir plus de 31 des tâches spécifiques qu'un utilisateur peut effectuer. De cette façon, le schéma de base de données serait plus simple, et nous n'aurions pas à modifier la structure de la table à chaque fois que nous avons ajouté une nouvelle tâche qui aurait besoin de contrôle d'accès. Comme ceci:

ID d'utilisateur des Permissions (8 bits de masque), serait ints dans le tableau
1 00001111
2 00000111
3 00000001

Quels sont les mécanismes qui ont les gens d'ici généralement utilisé, et pourquoi?

Merci!

Answer 1

Je pense que c'est une règle générale de rester à l'écart des chaînes de bits mystiques qui codent le sens de l'univers.

Bien que peut-être plus maladroit, avoir une table d'autorisations possibles, une table d'utilisateurs et une table de liens entre eux est la meilleure et la plus claire façon d'organiser cela. Cela facilite également vos requêtes et votre maintenance (en particulier pour le nouveau mec).

Answer 2

que diriez-vous de créer une table d'autorisation, puis une table UserPermission pour stocker les relations?

Vous n'aurez plus jamais à modifier la structure et vous avez la possibilité d'ajouter autant d'autorisations que vous le souhaitez.

Answer 3

Je l'ai fait dans les deux sens. Mais je n'utilise plus beaucoup de masques. Une table séparée serait très bien que vous pouvez utiliser comme référence croisée, étant donné un ID utilisateur ou un ID de groupe comme clé étrangère.

 UserID | Permission
===================
1      | 1              1 representing manage users
1      | 2              2 being manger products
2      | 3
 

Cette façon serait plus facile à entretenir et à ajouter plus tard.

J'utiliserais également une table distincte pour gérer les autorisations.

 PermissionID | Description
==========================
1            | Manage Users
2            | Manager Products
 

Answer 4

Généralement, j'ai une table des Utilisateurs, un tableau des Rôles, et un UserRoles table. De cette façon, vous pouvez avoir un nombre illimité de rôles sans changer de structure db et les utilisateurs peuvent être dans plusieurs rôles.

Je force l'application à n'autoriser que les contre rôles (jamais les utilisateurs). Remarquez comment le "id" de la colonne dans le tableau des rôles n'est pas une colonne d'identité. C'est parce que vous pouvez avoir besoin de contrôler les Id qui se mettre dans ce tableau parce que votre application va devoir chercher Id spécifiques.

La structure ressemble à ceci:

create table Users (
 id int identity not null,
 loginId varchar(30) not null,
 firstName varchar(50) not null,
 etc...
)

create table Roles (
 id int not null,
 name varchar(50) not null
)

create table UserRoles (
 userId int not null,
 roleId int not null
)

Answer 5

Je vous suggère de l'abstraction de votre application web autorisations avec l'idée d'un Rôle de Fournisseur. À partir de la version 2.0, il est fourni pour vous .NET en tant que Système.Web.De sécurité.RoleProvider.

L'idée de base est que vous tirer parti d'un cadre existant par l'écriture de vos contrôles d'autorisation en fonction du cadre plutôt qu'un mécanisme de stockage. Vous pouvez ensuite brancher-dans quel le mécanisme de stockage est disponible, si c'est un fichier XML, base de données, ou même un magasin d'autorisation à l'aide du logiciel Windows le Gestionnaire d'autorisations (qui vous permet de parfaitement s'articulent vos autorisations personnalisées pour LDAP, par exemple - pas de code requis pour la configuration).

Si vous décidez d'utiliser une base de données comme un mécanisme de stockage, plusieurs bases de données sont pris en charge pour la création automatique des tables sous-jacentes que le cadre doit. Cela inclut en cours d'exécution .NET sur Mono et en utilisant le rôle de fournisseur de modèle sur le dessus de MySQL.

Voir la mise en Œuvre d'un Rôle de Fournisseur pour plus d'informations. Il est tout à fait possible que d'autres langages/environnements aussi ont des bibliothèques vous pourriez tirer parti pour mettre en œuvre ce concept, il serait intéressant de regarder dans.

EDIT: je tiens également à souligner la configuration de la façon dont votre application web s'inscrit dans le mécanisme de stockage se fait par l'intermédiaire d'un site web.fichier de config, et ne nécessite pas de modification de code. J'ai trouvé cela très utile pour tester une version de production d'une base de code sur ma machine locale, à l'aide d'un fichier XML pour imiter les autorisations au lieu de la normale fournisseur de base de données - tout en modifiant deux lignes dans le web.config.

L'autre chose que j'ai oublié de mentionner, c'est que vous pouvez plug-in de vos propres fournisseurs en étendant les classes de base, vous permettant d'utiliser le modèle d'autorisation, mais tout de même utiliser une propriété du système de stockage (par exemple. des masques de bits, si vous avez vraiment voulu).