1、如何给多个子系统设计一个简单通用的权限管理方案
1.程序集和项目的关系，程序集，就是把.CS文件编译后生成的存放CLR能识别的MSIL语言(微软中间语言)的一个文件（如一个DLL文件或者一个exe文件都叫一个
2、谁能提供一个关于用户角色权限设计完整的方案。谢谢
User：用户表，存放用户信息
Role：角色表，存放角色信息
UserInRole：用户角色映射表，存放用户和角色的对就关系，多对多，一个用户可以对应多个
角色，而不同的角色有一同的权限。
Permissions：权限表，不同的角色对应不同的权限。权限信息使用一个字段flag来表示，
好处是可以使用位运算来计算权限，缺点是用位标识的权限受理论值限制，如int理论上可以
标识31种不同的权限, 当然可以整加一个字段来弥补，ApplicationID标识不同的模块
Application：模块信息。
[Flags]
public enum Flag:long
{
View=1,
Edit=2,
Delete=4
}
特性[Flag]告诉编译器,当编译器看到Flag枚举时，它会充许你用|(or)操作符组合枚举值，
就像二的整数幂一样，
例如 Flag Administer=Flag.View|Flag.Edit|Flag.Delete;表示三种权限的组合。
基础知识：
位运算
枚举Flag
当编译器看到Flag枚举时，它会充许你用|(or)操作符组合枚举值，
就像二的整数幂一样，
例如 Flag Administer=Flag.View|Flag.Edit|Flag.Delete;
常用操作，检查是否存在
Flag administer=Flag.View|Flag.Edit|Flag.Delete;
public bool Check(Flag administer,Flag mask)
{
bool bReturn = false;
if ((administer & mask) == mask)
bReturn = true;
return bReturn;
}
调用 Check(administer,Flag.Edit)将返回true.
public Flag SetBit(Flag administer,Flag mask)
{
return administer |= mask;
}
administer |= mask;操作相当于 administer = administer |mask;
从枚举中减去一种状态
administer &=mask;
如 :
Flag administer=Flag.View|Flag.Edit|Flag.Delete;
如需要禁止删除权限.
administer &=Flag.Delete;
另外，标记为flag的枚举类型，可以不设置值
public enum Flag:long
{
View,
Edit,
Delete
}
如需要设置，按以下规律， View=1,Edit=2,Delete=4,Reply=8按2次方累加，为什么会这样？因为他使用二进制操作，
当你使用 View=1,Edit=2,Delete=3,Reply=4这样的值， Flag.Delete 包含的值是Flag.Delete还是View=1|Edit=2就无从检测了.
每个用户，可以属于不同的角色不同的角色分配不同的权限，计算所有解权的所有可能的权限组合，只要有充许的权限，那么该用户既获取该权限。
在CS系统中，Permissions表合用了二个字段来标识权限.
AllowMask,DenyMask 规责是Deny优先,也就是说当权限标记为Deny那么不论是否Allow一律禁止该用户进行此项操作。
另外，像论坛类的权限设计，仅仅一个ApplicationID字段是不够用的，因为每个版块都需要设置不同的权限，来控制权限的粒度，可在增加一张Permission表，ApplicationID修改为版块ID
这样，就可以针对不同的版块设置不同的权限
好了，接下的问题是怎么和.net自带的权限系统挂钩了。。
在asp.net系统中 ，HttpContext.Current.User实现了一个接口IPrincipal,IPrincipal包含了另一个接口Identity
我们在设计User类的时候继承此接口
public class User:IPrincipal
{
string username;
public string Username
{
get{return username;}
set{username=value;}
}
}
实现IPrincipal接口方法
public IIdentity Identity
{
get {
if (!string.IsNullOrEmpty(username))
_Identity = new GenericIdentity(username,"Forums");
return (IIdentity)_Identity;
}
}
public bool IsInRole(string role)
{
.....
}
怎样和asp.net挂钩呢，这里可以在登陆时做检查
if(HttpContext.Current!=null){
User u= Users.GetUser(name);
HttpContext.Current.User =u;
在使用时
User u = HttpContext.Current.User as User;
当然检查用户角色可以直接用
if(HttpContext.Current.User.Identity.IsAuthenticated&&HttpContext.Current.User.IsInRole(角色名))
另外可以直接把到当用户权限策略挂接到当前线程 ,使用以下方法
AppDomain.CurrentDomain.SetPrincipalPolicy(User);
好了，接下来，怎么check权限？
我倾向于使用Attribute
[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method | AttributeTargets.Property | AttributeTargets.Delegate, Inherited = true, AllowMultiple = true)]
public class CheckPermissionAttribute : Attribute
{
int appID;
public int ApplicationID
{
get { return appID; }
set { appID = value; }
}
Permission _allMask;
public Permission AllMask
{
get { return _allMask; }
set { _allMask = value; }
}
public CheckPermissionAttribute(ApplicationID app, Permission allMask)
{
appID = app;
_allMask = allMask;
}
public CheckPermissionAttribute(Permission allMask)
{
_allMask = allMask;
}
}
AttributeUsage 第一个参数表示该属性可以应用于类，方法，属性，代理上
Inherited 检查继承的权限。
AllowMultiple 充许多次应用。
按下来，设计一个基类,继承自Page：
public class PageBase : Page
{
Flag _allMask;
/// <summary>
/// 检查类型权限
/// </summary>
public void CheckClass()
{
Type type = this.GetType();
CheckPermissionAttribute att = (CheckPermissionAttribute)CheckPermissionAttribute.GetCustomAttribute(type, typeof(CheckPermissionAttribute));
if (att != null)
{
Check(att.AllMask);
}
}
/// <summary>
/// 检查函数调用权限
/// </summary>
/// <param name="methodName">方法名</param>
public void CheckMethod(string methodName)
{
Type type = this.GetType();
string name = "*";
if (!string.IsNullOrEmpty(methodName))
name = methodName;
MemberInfo[] mis = type.FindMembers(MemberTypes.Method ,BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.IgnoreCase,Type.FilterNameIgnoreCase,name);
foreach (MethodInfo m in mis)
{
CheckPermissionAttribute att = (CheckPermissionAttribute)CheckPermissionAttribute.GetCustomAttribute(m, typeof(CheckPermissionAttribute));
if (att != null)
{
Check(att.AllMask);
}
}
return;
}
public void Check(Flag permissions)
{
if (!CheckPermission(permissions))
{
string url = string.Format("MsgPage.aspx?msg={0}", HttpUtility.UrlEncode("您没有权限访问该资源"));
Response.Redirect(url);
}
}
public void Check(ApplicationID appID, Flag permissions)
{
PermissionManager pm= Spaces.PermissionManager.Instance(appType);
if (!CheckPermission(pm,permissions))
{
string url = string.Format("MsgPage.aspx?msg={0}", HttpUtility.UrlEncode("您没有权限访问该资源"));
Response.Redirect(url);
}
}
protected override void OnInit(EventArgs e)
{
CheckClass();
base.OnInit(e);
}
}
如何使用：
[CheckPermission(2, Flag.View)]
public partial class MyPage : PageBase
{
}
若没有查看权限，会自运导向错误页面。
在类上应用挺方便。
方法上应用我于一个方法比较麻烦，我还没有找到在页面class里怎么获取当前调用的类名.
可以调用 CheckMethod(方法名称);如
[CheckPermission(2, Flag.Delete)]
public partial class MyPage : PageBase
{
public void test()
{
CheckMethod("test");
.......
}
}
3、大家的权限都是怎么实现的，有什么好的方案没有？ 欢迎交流如题 谢谢了
多角色的情况一般来说是很普遍的，很难将每一个用户的功能都抽象为角色进行单一的角专色赋权属。给给用户单独赋予权限是一种变通的解决办法，但是一不小很容易失控造成角色和权限的混乱。 数据权限如果有两个或更多维度的话应该如何处理呢? 比如：分地区、类型两种维度 省日化经理只能看本省范围内日化产品的销售情况，城市经理能看到本市范围全部商品的销售情况等等 如果不同的角色对于同一个功能有不同的数据范围要求，如何能设计一个良好的通用模型？。 查看原帖>>
4、怎么做后台的权限管理模块
需要做一个cms网站，PHP+MySQL的，网站后台要有不同角色的不同管理权限，比如超级管理员拥有所有管专理权限，编辑员只能发布属信息，审核员只能删除垃圾文章图片。------解决方案--------------------------------------------------------探讨需要做一个cms网站，PHP+MySQL的，网站后台要有不同角色的不同管理权限，比如超级管理员拥有所有管理权限，编辑员只能发布信息，审核员只能删除垃圾文章图片。
5、asp 如何设置浏览权限
使用 Internet 信息服务 (IIS) 管理器，可以创建用来承载 ASP.NET Web 应用程序的本地网站。本主题解内释如何创建本地网站以及如容何将它配置为运行 ASP.NET 页。有关安装和配置 IIS 或者创建网站的更多详细信息，请参见包含在 IIS 中的 IIS 帮助文档或者 Microsoft TechNet 网站上的联机 IIS 产品文档。
创建本地站点的另一种方法是创建虚拟目录。这提供了一种实现如下方案的方法：在一台计算机上承载网站，而将该网站的实际页和内容包含在根目录或主目录以外的某个位置，如远程计算机。这也是一种为本地 Web 开发工作设置站点的方便方法，因为它不需要唯一的站点标识，这意味着它比创建唯一站点所需要的步骤少
6、基于RESTful API 怎么设计用户权限控制
本文是基于RESTful描述的，需要你对这个有初步的了解。
RESTful是什么？
Representational State Transfer，简称REST，是Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格。
REST比较重要的点是资源和状态转换，
所谓"资源"，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。
而"状态转换"，则是把对应的HTTP协议里面，四个表示操作方式的动词分别对应四种基本操作：
1. GET，用来浏览(browse)资源
2. POST，用来新建(create)资源
3. PUT，用来更新(update)资源
4. DELETE，用来删除(delete)资源。
资源的分类及操作
清楚了资源的概念，然后再来对资源进行一下分类，我把资源分为下面三类：
1. 私人资源 (Personal Source)
2. 角色资源 (Roles Source)
3. 公共资源 (Public Source)
"私人资源"：是属于某一个用户所有的资源，只有用户本人才能操作，其他用户不能操作。例如用户的个人信息、订单、收货地址等等。
"角色资源"：与私人资源不同，角色资源范畴更大，一个角色可以对应多个人，也就是一群人。如果给某角色分配了权限，那么只有身为该角色的用户才能拥有这些权限。例如系统资源只能够管理员操作，一般用户不能操作。
"公共资源"：所有人无论角色都能够访问并操作的资源。
而对资源的操作，无非就是分为四种：
1. 浏览 (browse)
2. 新增 (create)
3. 更新 (update)
4. 删除 (delete)
角色、用户、权限之间的关系
角色和用户的概念，自不用多说，大家都懂，但是权限的概念需要提一提。
"权限"，就是资源与操作的一套组合，例如"增加用户"是一种权限，"删除用户"是一种权限，所以对于一种资源所对应的权限有且只有四种。
角色与用户的关系：一个角色对应一群用户，一个用户也可以扮演多个角色，所以它们是多对多的关系。
角色与权限的关系：一个角色拥有一堆权限，一个权限却只能属于一个角色，所以它们是一(角色)对多(权限)的关系
权限与用户的关系：由于一个用户可以扮演多个角色，一个角色拥有多个权限，所以用户与权限是间接的多对多关系。
需要注意两种特别情况：
1. 私人资源与用户的关系，一种私人资源对应的四种权限只能属于一个用户，所以这种情况下，用户和权限是一(用户)对多(权限)的关系。
2. 超级管理员的角色，这个角色是神一般的存在，能无视一切阻碍，对所有资源拥有绝对权限，甭管你是私人资源还是角色资源。
数据库表的设计
角色、用户、权限的模型应该怎么样设计，才能满足它们之间的关系？
对上图的一些关键字段进行说明：
Source
name: 资源的名称，也就是其他模型的名称，例如：user、role等等。
identity: 资源的唯一标识，可以像uuid，shortid这些字符串，也可以是model的名称。
permissions : 一种资源对应有四种权限，分别对这种资源的browse、create、update、delete
Permission
source : 该权限对应的资源，也就是Source的某一条记录的唯一标识
action ：对应资源的操作，只能是browse、create、update、delete四个之一
relation：用来标记该权限是属于私人的，还是角色的，用于OwnerPolicy检测
roles: 拥有该权限的角色
Role
users : 角色所对应的用户群，一个角色可以对应多个用户
permissions: 权限列表，一个角色拥有多项权利
User
createBy : 该记录的拥有者，在user标里，一般等于该记录的唯一标识，这一属性用于OwnerPolicy的检测，其他私有资源的模型设计，也需要加上这一字段来标识资源的拥有者。
roles : 用户所拥有的角色
策略/过滤器
在sails下称为策略(Policy)，在java
SSH下称为过滤器(Filter)，无论名称如何，他们工作原理是大同小异的，主要是在一条HTTP请求访问一个Controller下的action
之前进行检测。所以在这一层，我们可以自定义一些策略/过滤器来实现权限控制。
为行文方便，下面姑且允许我使用策略这一词。
*策略 (Policy) *
下面排版顺序对应Policy的运行顺序
SessionAuthPolicy：
检测用户是否已经登录，用户登录是进行下面检测的前提。
SourcePolicy：
检测访问的资源是否存在，主要检测Source表的记录
PermissionPolicy：
检测该用户所属的角色，是否有对所访问资源进行对应操作的权限。
OwnerPolicy：
如果所访问的资源属于私人资源，则检测当前用户是否该资源的拥有者。
如果通过所有policy的检测，则把请求转发到目标action。
7、请教XX管理系统的前端页面展示和后端权限控制的一般解决方案
前端面向的是抄用户编程，就袭是用户可以看得到摸得到的。UI就是其中的一部分。后端是面向服务(服务器)编程，用户是无须知道里面的操作的。举个例子。比如简单的登陆功能。前端的只要做好两个文本控件与一个按钮控件，并且监听按钮的点击事件，将两个文本的参数按照协议发送到服务器端上。这就是前端要做的。而后端，服务器就要接收发送过来的消息并且调用数据库验证用户名与密码。成功后返回结果。
8、JAVA权限设计模块，设计思路。网上的不要，请根据我的需求来，谢谢了啊。好了我还会加分。
不知来道你们的需求要细到什么自程度，只能说个大概
最基本的权限管理是要定义角色和权限
每个用户都有若干角色身份，比如项目负责人，项目参与者都是角色
权限就是操作，比如下载数据，浏览项目这些都是权限
角色表和权限表是多对多的关系
如果要给某个用户分配某个权限，就把一个权限和一个角色关联起来，同时确保这个用户有这个被关联的角色身份，这样就可以通过用户查角色，通过角色查关联权限，如果用户有关联当前操作需要的权限，就可以通过了。
以上是粗粒度的方法级权限管理的基本思想
细粒度的数据级权限控制要复杂得多，比如有两个项目，两个用户分别是它们的项目组长，而每个用户只能管自己的那个项目组，因为他们角色都是项目组长，所以就不能用上面的方法来验证权限了。
解决方案说来话长，采纳以后可以hi我详细说
授权时间可以使用定时器，到一定时间以后将角色和权限的关联关系删掉，也可以定期轮循检查，发现有权限过期了就删掉，前提当然是你的权限关联要记好生效时间和有效期
9、软件设计后台操作用户权限管理的方案
B/S系统中的权限比C/S中的更显的重要，C/S系统因为具有特殊的客户端，所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现，而B/S中，浏览器是每一台计算机都已具备的，如果不建立一个完整的权限检测，那么一个“非法用户”很可能就能通过浏览器轻易访问到B/S系统中的所有功能。因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测，让经过授权的用户可以正常合法的使用已授权功能，而对那些未经授权的“非法用户”将会将他们彻底的“拒之门外”。下面就让我们一起了解一下如何设计可以满足大部分B/S系统中对用户功能权限控制的权限系统。
需求陈述
不同职责的人员，对于系统操作的权限应该是不同的。优秀的业务系统，这是最基本的功能。
可以对“组”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便的事情。所以，系统中就提出了对“组”进行操作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。
权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。
满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。
关于设计
借助NoahWeb的动作编程理念，在设计阶段，系统设计人员无须考虑程序结构的设计，而是从程序流程以及数据库结构开始入手。为了实现需求，数据库的设计可谓及其重要，无论是“组”操作的概念，还是整套权限管理系统的重用性，都在于数据库的设计。
我们先来分析一下数据库结构：
首先，action表（以下简称为“权限表”），gorupmanager表（以下简称为“管理组表”），以及master表（以下简称为“人员表”），是三张实体表，它们依次记录着“权限”的信息，“管理组”的信息和“人员”的信息。如下图：
这三个表之间的关系是多对多的，一个权限可能同时属于多个管理组，一个管理组中也可能同时包含多个权限。同样的道理，一个人员可能同时属于多个管理组，而一个管理组中也可能同时包含多个人员。如下图：
由于这三张表之间存在着多对多的关系，那么它们之间的交互，最好使用另外两张表来完成。而这两张表起着映射的作用，分别是“actiongroup”表（以下简称“权限映射表”）和“mastergroup”表（以下简称“人员映射表”），前者映射了权限表与管理组表之间的交互。后者映射了人员表与管理组表之间的交互。如下图：
另外，还需要一张表来控制系统运行时左侧菜单中的权限分栏，也就是“权限分栏表”，如下图：
根据上面的分析，我们进行数据库结构设计，如下图：
点击这里查看权限管理系统数据表字段设计
为了能够进行良好的分析，我们将数据库结构图拆分开来，三张实体表的作用已经很清晰，现在我们来看一下两张映射表的作用。
一 权限映射表 如下图：
首先，我们来了解一下权限映射表与管理组表以及权限表之间的字段关联。
看图中的红圈，先看gorupid字段相关联，这种关联方式在实际数据库中的表现如下图：
如图中所示，管理组表中“超级管理员”的groupid为1，那么权限映射表中groupid为1的权限也就是“超级管理员”所拥有的权限。
使用groupid字段关联，是为了查到一个管理组能够执行的权限有哪些。但这些权限的详细信息却是action字段关联所查询到的。
action字段相关联在数据库中的表现如下图：
通过这种关联，才查询到权限映射表之中那些权限的详细信息。综合起来，我们就知道了一个管理组可以执行的权限有哪些，以及这些权限的详细信息是什么。
或许你会问，为什么不使用actionid字段相关联呢？因为：
权限表中的id字段在经过多次的数据库操作之后可能会发生更改。
权限映射表中仅仅记录着一个管理组可以执行的权限。
一旦权限表中的id更改，那么权限映射表中的记录也就更改了。
一个管理组可以执行的权限势必将出错，这是非常不希望的。
考虑到上面的情况，所以应该使用action字段相关联，因为：
在权限表中，id可能发生变化，而action字段却是在任何情况下也不可能发生变化的。
权限映射表中记录的action字段也就不会变。
一个管理组可以执行的权限就不会出错了。
二 人员映射表 如下图：
我们来了解一下人员映射表与管理组表以及人员表之间的字段关联，如下图：
看图中的红圈部分，先看groupid字段关联，这种关联方式在数据库中的表现如下图：
如图，“超级管理员”组的groupid为1，我们再看人员映射表，admin属于超级管理员组，而administrator属于超级管理员组，同时也属于管理员组。
使用这种关联方式，是为了查到一个管理组中的人员有谁。和上面一样，人员的详细信息是靠id字段（人员映射表中是masterid字段）关联查询到的。
id字段（人员映射表中是masterid字段）关联表现在数据库中的形式如下图：
一个人员可能同时属于多个“管理组”，如图中，administrator就同时属于两个“管理组”。所以，在人员映射表中关于administrator的记录就会是两条。
这种关联方式才查询到管理组中人员的详细信息有哪些。综合起来，才可以知道一个管理组中的人员有谁，以及这个人员的详细信息。
再结合上面谈到的权限表和权限映射表，就实现了需求中的“组”操作，如下图：
其实，管理组表中仅仅记录着组的基本信息，如名称，组id等等。至于一个组中人员的详细信息，以及该组能够执行的权限的详细信息，都记录在人员表和权限表中。两张映射表才真正记录着一个组有哪些人员，能够执行哪些权限。通过两张映射表的衔接，三张实体表之间的交互才得以实现，从而完成了需求中提到的“组”操作。
我们再来看一下权限分栏表与权限表之间的交互。这两张表之间的字段关联如下图：
两张表使用了actioncolumnid字段相关联，这种关联方式在数据库中的表现如下图：
如图所示，通过这种关联方式，我们可以非常清晰的看到权限表中的权限属于哪个分栏。
现在，数据库结构已经很清晰了，分配权限的功能以及“组”操作都已经实现。下面我们再来分析一下需求中提到的关于权限管理系统的重用性问题。
为什么使用这种数据库设计方式搭建起来的系统可以重用呢？
三张实体表中记录着系统中的三个决定性元素。“权限”，“组”和“人”。而这三种元素可以任意添加，彼此之间不受影响。无论是那种类型的业务系统，这三个决定性元素是不会变的，也就意味着结构上不会变，而变的仅仅是数据。
两张映射表中记录着三个元素之间的关系。但这些关系完全是人为创建的，需要变化的时候，只是对数据库中的记录进行操作，无需改动结构。
权限分栏表中记录着系统使用时显示的分栏。无论是要添加分栏，修改分栏还是减少分栏，也只不过是操作记录而已。
综上所述，这样设计数据库，系统是完全可以重用的，并且经受得住“变更”考验的。
总结：
此套系统的重点在于，三张实体表牢牢地抓住了系统的核心成分，而两张映射表完美地映射出三张实体表之间的交互。其难点在于，理解映射表的工作，它记录着关系，并且实现了“组”操作的概念。而系统总体的设计是本着可以在不同的MIS系统中“重用”来满足不同系统的功能权限设置。
附录：
权限管理系统数据表的字段设计
下面我们来看看权限管理系统的数据库表设计，共分为六张表，如下图：
action表：
action表中记录着系统中所有的动作，以及动作相关描述。
actioncolumn表：
actioncolumn表中记录着动作的分栏，系统运行时，左侧菜单栏提供了几块不同的功能，每一块就是一个分栏，每添加一个分栏，该表中的记录就会增加一条,相对应的，左侧菜单栏中也会新增机一个栏。
actiongroup表：
actiongroup表记录着动作所在的组。
groupmanager表：
groupmanager表记录着管理组的相关信息，每添加一个管理组，这里的记录就会增加一条。
mastergroup表：
mastergroup表记录着管理员所在的管理组，由于一名管理员可能同同时属于多个组，所以该表中关于某一名管理员的记录可能有多条。
master表：
master表记录着所有管理员的信息，每添加一个管理员，该表就会增加一条记录。