题外话：
临近大四，编写各种简历的时候发现，很多电子简历上是可以链上自己在各大论坛上留下的足迹。关于这点，学习网络，拥抱开源，具有互联网思维的博主很后悔，后悔当年只会在网上查资料，不会留资料，空有才能不能表达。不过这都是往事啦，犯错早总比犯错晚好，明白错误的不早不晚也能接受。不过以后，我会尽自己所能在博客上分享一些学习到的知识。
回归正题：
关于权限管理，各位大神都有过自己的经历，现在就让我们跟随大神的脚步慢慢深入
一. 引言
在互联网时代，我们每天都会遇到各种权限，在你的电脑，你的手机中，你的每一次点击，每一次滑动都涉及到权限。博主高中时期最自豪的一件事，就是把当时的神机中兴u880使用线刷，把可恶的开关机铃声和一些预装软件给删了，并利用超级权限，修改手机各种图标且把自己下的软件都放到手机系统区。在Windows 操作系统中，存在用户、组的概念。当一个用户从属于Administrators 组的时候，他就能够进行操作系统的设置与修改以及安装应用程序、修改注册表等，而当一个用户从属于Guest 组的时候，就只能浏览被允许浏览的文件和运行系统管理员允许其他运行的软件。权限系统的设计在软件中普遍存在， 但现阶段世界中并没有十分完善的权限设计方法， 只有针对具体的软件需求设计出适合的权限系统。像IBM 等世界计算机巨头都在进行权限设计方面的理论研究， 虽有一些研究成果面向大型软件公司出售，但价格十分昂贵，一般消费者难以承受
二.权限介绍
博主自以为是的认为权限直观上就是不同角色对数据具有其应有的增删该查的操作。
每个软件都应该有这种最基本的需求。比如管理员能对数据进行增，删，查，改操作，对资源可以任意的浏览，而普通用户只能浏览限制资源，查询数据等功能。这些都包含在基本的需求当中。当然如果特殊的用户可以下载数据等这些特殊操作，这些就不在本文考虑范围之内，这都是一些可扩展工作。
下面介绍在通用OA中关于权限的几个需要自己创建的表，以及他们的简单属性以及相互之间的关系(部分解释引用他人见解)
1.用户表（UserInfo）
用户就是软件的使用者，凡是使用到该软件的都可以定义成用户。它应该有一些基本信息。
2.角色表（RoleInfo）
说起角色，博主一次对他有感觉是在oracle课上
1.create role ThisRole;2.grant create table to ThisRole;3.grant ThisRole to me;
角色就是软件使用者的身份，就像一个政府机构一样，什么样的身份，就有什么样的权利，而这里角色也就代表这用户的权限。
角色看似挡在用户和权限中间造成麻烦，其实恰恰相反。举2个例子：1.增加一个管理员，我们需要给他分别添加增删改查；再增加一个管理员，又需要分别为其增加增删改查；如果再来很多个呢？这样无疑很麻烦。但是如果先设置一个具有管理员权限的角色，增加管理员时只要给他添加管理员角色就可以避免这个麻烦。2.公司有很多不同职位的员工，总裁，总经理，副经理，财务处长。。。。。。普通员工。这时，我们就可以看出，应该先给这些职位设置相应角色，把角色赋给对应职位上的员工，就可以减少不必要的操作。而一个真正的大公司就是这样高效稳定的运行。
3.权限表（Action）
权限就是对某一个资源是否有浏览的权利，或者对某一个数据是否有操作的权利。
4.用户权限中间表（R_UserInfoAction）
这个表有别与其它中间表，它多了一个自己设定的布尔类型的属性HasPermission.
介绍原因：在使用vs .edmx模板创建OA关于权限的表时，每两个表是如果是多对多关系，生成数据库时，则会自动生成一个中间表，但是如果希望这个中间表具有其它操作（如软禁总经理）时，呆萌的vs并不会帮你为自动生成的中间表添加额外属性，所以需要自己创建这个表。
对于此表图4有分析
三.权限设计
一般常用的权限设计模式有两种
1.基于角色
这种方案是最常见也是比较简单的方案，不过通常有这种设计已经够了，所以微软就设计出这种方案的通用做法，可以看到微软在asp.net2.0中，就可以直接创建用户角色及用户，它不对每一个数据操作进行权限控制，而是对角色资源访问进行控制。可以指定那些角色不能访问哪些资源等，而这些权限控制配置在web.config中。可以看到这种设计方案肯定不是通用的，因为需求完全可能提出对数据的控制。例如:销售人员不能增加商品，但是可以查询修改数据。
用户可以有多个角色，一个角色对应着多个用户，所以用户和角色之间对应关系式多对多的关系。
2. 基于操作
这种模式下每一个操作都在数据库中有记录，用户是否拥有该操作的权限也在数据库中有记录。但是这样存在一个问题：存放这个权限记录的数据库表数据量比较大，对用户每个操作都要查询数据库，这样效率很低。
一个用户可以拥有多种权限，一种权限也对应多个用户，所以权限与数据库之间关系式多对多的关系。
但是如果直接使用上面的设计，会导致数据库中的UserAction这张表数据量非常大，所以我们需要进一步设计提高效率，请看方案3
3.基于角色和操作的权限设计
这下用户、角色和权限终于都齐了。这样子可以减少UserAction中的记录，并且使设计更灵活一点。
但是这种方案在用户需求的考验之下也可能显得不够灵活够用，例如当用户要求临时给某位普通员工某操作权限时，我们就需要新增加一种新的用户角色，但是这种用户角色是不必要的，因为它只是一种临时的角色，如果添加一种角色还需要在收回此普通员工权限时删除此角色，我们需要设计一种更合适的结构来满足用户对权限设置的要求。
4.2,3组合的权限设计，其结构如下：
我们可以看到在上图中添加了UserAction表，使用此表来添加特殊用户的权限，改表中有一个字段HasPermission可以决定用户是否有某种操作的权限，改表中记录的权限的优先级要高于UserRole中记录的用户权限。这样在应用程序中我们就需要通过UserRole和UserAction两张表中的记录判断权限。
到这儿呢并不算完，有可能用户还会给出这样的需求：对于某一种action所操作的对象某一些记录会有权限，而对于其他的记录没有权限，比如说一个内容管理系统，对于某一些频道某个用户有修改的权限，而对于另外一些频道没有修改的权限，这时候我们需要设计更复杂的权限机制。
5. 对于同一种实体（资源）用户可以对一部分记录有权限，而对于另外一些记录没有权限的权限设计：
对于这样的需求我们就需要对每一种不同的资源创建一张权限表，在上图中对Content和Channel两种资源分别创建了UserActionContent和UserActionChannel表用来定义用户对某条记录是否有权限；这种设计是可以满足用户需求的但是不是很经济，UserActionChannel和UserActionContent中的记录会很多，而在实际的应用中并非需要记录所有的记录的权限信息，有时候可能只是一种规则，比如说对于根Channel什么级别的人有权限；这时候呢我们就可以定义些规则来判断用户权限（判断规则请各位看官自行脑补）
资料来源：时间久远，存在本地，找不到链接了。。。。。。