权限设计
B/S系统中的来权限比自C/S中的更显的重要，C/S系统因为具有特殊的客户端，所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现，而B/S中，浏览器是每一台计算机都已具备的，如果不建立一个完整的权限检测，那么一个“非法用户”很可能就能通过浏览器轻易访问到B/S系统中的所有功能。因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测，让经过授权的用户可以正常合法的使用已授权功能，而对那些未经授权的“非法用户”将会将他们彻底的“拒之门外”。下面就让我们一起了解一下如何设计可以满足大部分B/S系统中对用户功能权限控制的权限系统。
㈡ 谁能说说权限是如何设计的
权限设计目前为止都没有一个最完美的设计，只有一个最适合的设计
比如WINDOWS,本身设计也就是到了角色的级别，如果WINDOWS权限能够控制到文件，文件夹，甚至是文件的某一行，相反还太过繁琐，属于设计过度。
在软件开发中,为软件加入权限控制功能,使不同的用户有不同的使用权限,是非常重要的一项功能,由其在开发数据库方面的应用,这项功能更为重要。一般均以菜单访问功能的形式出现,按照常规的做法,只要让注册进入应用的不同用户,可以访问不同的功能菜单,从而实现功能权限的控制,但是,有这样一个问题,此种方法便无能为力,现在的应用软件,为了提高软件的易操作性,同一功能可能有多种不同的访问方式,如工具条,右键菜单等；同样,同一个功能,也可能在软件的不同地方被调用,而不仅仅被限制为用程序的主菜单来调用,这样,才能保证应用的易用性。
目前使用的比较多的设计方法一般是基于角色的，即
用户——角色——权限
判断一个用户有没有权限做某件事情，先判断该用户所属的角色，然后查看该角色的权限，通过查找出来的权限，来判断该用户能否进行操作。
数据库的设计可以参考以下：
http://www.cnblogs.com/wuhuacong/archive/2009/06/19/1507065.html
㈢ 有关设计代表权限的规范。
两个人要是都拍不了板，那就找能拍板的人啊。
㈣ 谁能提供一个关于用户角色权限设计完整的方案。谢谢
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");
.......
}
}
㈤ javaweb 项目的系统权限管理，怎么设计
java web 项目来的系统权限管理设计方法有两自种：
方法一、SpringMVC整合Shiro （Shiro是强大的权限管理框架）
参考：http://www.360doc.com/content/14/0529/09/11298474_381916189.shtml
方法二、基于角色的访问权限控制
基于角色的访问权限控制
首先基于角色的访问权限控制，所有的用户访问都会经过过滤，然后分析访问权限加以认证！权限中的重点，表的设计。
普遍三张表，表名自定义。用户表（User），角色表（Role），资源表（Resource）
用户表没有特别，很简单。关键是角色表和资源表。
㈥ 如何设计用户、角色、权限表
用户
:ID
UserName
角色与用户关系表:ID
userID
RoleID
角色:ID
RoleName
角色与权限项关版系表:ID
权限项表ID
RoleID,Effectiveness
--显示这权限是否有效
权限项表
ID
Name
----------------
同1楼一致，只是权多了Effectiveness
--显示这权限是否有效
㈦ 权限系统设计
请你参考RBAC通用设计，这个是通用的，理解后实现简单，不限语言
㈧ 权限设计问题
一、概要
通常，需要单独的权限系统是解决授权的管理和维护，再分配等难题，不针对开发而言。
系统架构目标：在易于理解和管理，开发的前提下，满足绝大部分粗粒度和细粒度权限控制的功能需要。
除了粗粒度权限，系统中必然还会包括无数对具体Instance的细粒度权限。这些问题，被留给对框架的扩展方法来解决，这样的考虑基于以下两点：
1、细粒度的权限判断必须要在资源上获取权限分配的支持的上下文信息才可能得以实现。
2、细粒度的权限常常具有相当大的业务逻辑相关性。对不同的业务逻辑，常常意味着完全不同的权限判定原则和策略。相比之下，粗粒度的权限更具通用性，将其实现为一个架构，更有重用价值；而将细粒度的权限判断实现为一个架构级别的东西就显得繁琐，增加架构的复杂性。而且不是那么的有必要，用定制的代码来实现就更简洁，更灵活。否则会变成各种逻辑代码的堆砌。
比如，proct post数量的控制，这种一般要知道用户个性化的信息，付钱数量到数据库中查找最高数量，还要知道此用户已经有多少产品等，规则不具备通用性和重用性，
所以细粒度控制不应该放在权限架构层来解决。实例级的细粒度权限的解决方案就是将它转化为粗粒度权限，这样我们权限客户端就变得很简单了。
名词解释
粗粒度权限：一般可以通过配置文件来授权，授权只有真假，没有多少之分，不需要上下文的支持。不消耗资源的。
逻辑表达式：判断“Who对What(Which)进行How的操作”的逻辑表达式是否为真。
别名：静态授权、类级授权
细粒度权限：不能通过配置文件等表达，需要特定上下文的支持.
逻辑表达式：判断“When(Where)的时候，Who对What(Which)进行How的操作”的逻辑表达式是否为真。
别名：动态授权、实例级授权
设计原则：框架只提供粗粒度的权限。细粒度的权限也需要集中管理和维护，细粒度的权限通过定制的扩展代码将细粒度转化为粗粒度授权。
二、权限系统的设计
权限往往是一个极其复杂的问题， 设计权限系统第一个要解决的问题就是什么样的行为是需要权限控制，什么样的是业务方法。他们之间本来是没有明确的区分，任何权限从某种角度上说可以是一种业务方法。为了以后管理和开发方面我们从概念上需要将权限和业务明确划分清楚，指导开发。
权限控制行为： 对What(Which)进行How的操作需要区分Who，具有Who身份差异性和可替换性。 我们将此类操作作为权限。
特点： 可以收回也可以分配的，具有一定的抽象级别。 消耗资源，行为结果具备一些持久性的影响。
业务逻辑行为： 对What(Which)进行How的操作的时候与Who的身份无关或者具有Who身份差异性但 是不具有可替换性。
特点： 不能抽象和共享，很难回收和分配。不消耗资源，不产生持久性。现实中也存在某一时期行为是业务逻辑，最后演变成权限控制，或者相反的过程。
1、粗粒度权限设计
采用自主型访问控制方法，操作给予访问控制列表。每一个用户通过角色获得一组权限集合，权限系统的功能是验证用户申请的权限（集合）是否在这个集合当中，即申请的权限（集合）是否投影在用户拥有的权限集合,换句话说：只要某用户直接或者间接的属于某个Role那么它就具备这个Role的所有权限许可。
一个自主型访问控制方法的权限系统包括以下几个部分：角色、权限、访问控制表、
（1）权限
描述一个权限可以通过以下几个要素说明：
类型（class）:
名称（name）：
动作(actions)：
掩码（mask）：
属性：
具体权限Example:
1、Test
类型（class）:com.yangjs.secutiry. permissions. TestPermission
名称（name）：如：test.* ，test.sub.* ,test.sub1.sub2
动作(actions)： brower_detail ,post,repost,……
掩码（mask）：0x1,0x2,0x4…..
属性： 无
.…………..
l 存取控制器（my--acl.xml）配置
存取控制项（ACE）：角色到权限的映射集合，表示某个角色可以在某些资源上执行某些动作，它们之间通过role关联（继承），ACE之间产生包含关系。
存取控制列表（ACL）：ACE的集合。
我们的存取控制器（ACL）是通过一个xml的配置文件说明，存取控制列表由多个存取控制项（ACE）来描述。使用方法(略）
2、细粒度权限设计
细粒度授权需要上下文的支持，而且每个权限控制的上下问题都不一样，这由相关的业务逻辑决定，而且此类授权一般变化较快，应此需要将强的可维护性和扩展性，支持变化，但又不能够太复杂，否则缺乏可执行性。虽然此类权限个性化较强，我们仍然可以总结出很多共性：
（1） 几乎所有的授权需要用户的角色和ID.
（2） 特定的上下文几乎都同用户资源使用情况相关.
我们将此类信息称为UserState 即：User角色以及资源使用情况和当前状态。大部分信息我们在用户登陆的时候已经。获得。授权贯穿Web层和Biz层，因此我们的登陆要独立于Web端。因此上下文我们可以用UserState结合其他来抽象。
关于上下文的维护问题，我们不可能将UserState此类参数在Web层和Biz层来回传递，更加不能在需要授权的地方都加上一个这样的方法参数，这样不太现实。其次如果在授权的地方再从数据库中取一次这样虽然能够解决部分问题（不能解决userId的传递），这样效率太低，不能接受。
解决方法就是将此类信息cache起来，用的时候再去取，由于此类信息具有非常高的并发性，对线程安全较高，因此我们决定将此类信息放入一个线程上下文的内存cache中。此外我们由于引入cache，就需要解决所有cache共有的维护性问题。
Cache的生命周期：用户的一次请求，属于线程级，用户请求线程结束，Cache结束。
Cache的更新：当上下文信息发生变化是需要及时更新Cache，这是一个不可避免的步骤。
Cache丢失：发生在如系统down机，线程崩溃，内存溢出等等，对用户来说就是当前请求突然中断。
当用户重新发送请求，我们的系统就需要重新验证用户，此时我们可以更新Cache解决丢失问题。
Cache的清理：这个实现就是当用户请求结束，返回应答的时候清理，可以通过Filter实现，比较简单。
以上是相关的原理部分，我们看看系统地实现：
实现：线程上下文的cache
实现类：com.yangjs.cache.ThreadContextCache:
public class ThreadContextCache {
public static Map asMap()；
public static boolean containsKey(Object key)；
public static boolean containsValue(Object key)；
public static Object get(Object key)；
public static void put(Object key, Object value)；
public static Object remove(Object key)；
public static void clean()；
public static int size() ；
public static void destroy()
㈨ 关于权限设计
字段可以设置成抄角色、功能模块、权限袭标志
每个功能模块为一条记录 然后权限标志假定为1和0 ，1为可以进入0为不可进入
进入的时候Select * From 表Where 角色 = '当前角色'And功能模块='要进入的功能模块名称' 如果 权限标志为1允许为0则不允许
或者进入的时候Select * From 表Where 角色 = '当前角色' And 功能模块='要进入的功能模块名称' And 权限标志 = '1' 如果查询到的记录数大于0 则允许进入
㈩ 用户权限设计
基于角色的访问控制模型就是把“用户—角色—操作—资源”关联到一起，实现非自主型访问控制策略。使用基于角色的访问控制模型可以减轻安全管理工作，因为某种任务是稳定的，而负责该项任务的人员是经常变化的，这种方式只需把新的用户分配给已有的角色即可，无需为用户重新指定资源和操作，因而简化了授权管理工作。
为了保障本系统操作使用的信息安全，系统登录认证体系由三个要素组成:用户、角色、权限，三者相辅相成，共同组成系统的安全运行屏障。
1.用户信息
用户信息表统一管理，在用户信息表中存储用户名称、登录名、口令、各子系统权限、用户角色信息等。
用户信息表的添加、删除以及子系统权限修改由总系统授权的管理员执行，本系统中，用户信息表的操作在业务处理与信息服务子系统的系统管理菜单下的用户信息管理页面。用户口令可以自行改变，用户权限的变更需要提请管理员同意，并由管理员修改。
子系统启动时读取用户信息表验证用户权限，在系统运行时依据权限分配相应的功能。依据用户在子系统中的权限级别控制用户可操作的功能，实现最终用户对ORACLE数据库中数据的读取和添加操作权限控制(表8－2)。
表8－2 用户信息结构表
2.角色信息
角色可以根据需要任意多地添加，多个角色权限组合生成多个权限控制，对应到一个确定的用户，赋予用户对功能模块的控制权限。用户角色表包括角色名称、用户唯一值编码等信息。示例见表8－3。
表8－3 用户角色表(示例)
在数据库中为各个功能模块建立了功能名称表，每个功能模块均有记录，有功能编码和功能名称及其他附属信息。功能名称示例见表8－4。
表8－4 功能名称表(示例)
每个用户必须属于至少一个角色，每个角色具备多个功能的控制权限，功能权限通过角色传递给用户，从而实现用户对功能的操作权限控制。
3.权限信息
权限表明了用户可执行的操作。系统权限控制采用最大优先，用户可以拥有多个角色，每个角色对每一页面都可拥有权限，但在权限结果判断时只以最大权限为主，即管理员级权限大于并包含访问者权限。功能权限示例如表8－5所示。
表8－5 功能权限表(示例)
系统规划的子系统权限等级见表8－6。
表8－6 子系统权限等级规划表(部分)
续表
4.用户认证授权
通过以上四个表将用户、角色与权限组合起来，可以形成无穷多的用户权限组合，直接控制用户权限到每个细分功能。
用户、角色、权限、功能控制流程如图8－1所示:
图8－1 用户权限控制流程图
功能权限表仅在部署角色权限时使用，标示功能具备的可部署权限。
在角色中必须保证有一个管理角色拥有用户管理功能的管理权限，防止不能分配角色与权限，同样在用户中必须保证至少有一个用户是管理角色。