通常在实现某种基于角色的访问控制时，我们有以下众所周知的概念:
- 用户
用户将被分配到角色，每个角色都有一组权限(执行操作/访问资源等)。因此，用户通过被分配给一个或多个角色(这些角色已经被分配了一组权限)来获得执行操作的权限。
在任何给定的应用程序中，权限都是在编译时定义的，因为代码实际上在访问资源的各个地方强制执行权限。
我的想法是，如果可能的权限/操作集发生变化-它需要更改代码和重新编译任何方式，所以在数据库中有一个查找/引用表将不会真正提供任何价值，除了db管理员可以做一个快速的sql查询来列出应用程序使用的所有权限。
然而，我见过的大多数应用程序都为权限创建了一个查找表，并将其映射到代码中的enum。
考虑到这一点，是否有任何理由实际上有一个数据库表表示可能的权限列表(除了事实，它可能更容易在数据库中查找，而不是挖掘到代码中找到权限列表/枚举)?
清单:1)您是否需要在网站在线时进行更改，而不会停机?2)您将使用内置的角色/会员提供程序吗?3)你想使用属性(如mvc[授权])等?4)您希望允许用户以编程方式更改权限/角色?
以上任何一种都意味着你必须将信息存储在数据库上。
对于较小规模的应用程序，我更喜欢创建一些静态方法，也使用某种继承，例如:
isadmin()
{
if (usernameArray.Contains[currentname])
return true;
[...]
}
ispublisher()
{
if (isadmin()) return true;
[...]
}
和一个表的权限为每个用户伪类。
Update: DB schema for specific access: (* is key， &是外键)
Users:
Username *
[...]
UserClasses (EG: admin...)
ID *
description
AccessTypes (EG: can delete)
ID *
description
UserClassesAssign
classid *&
username *&
AccessPerClass
accessid *&
classid *&
所以任何时候你想看看'username'是否能够'CanDelete'你必须检查用户'username'是否链接到任何类链接到访问'CanDelete'，这些链接当然可以在运行时改变