共同进退，荣辱与共（技术专栏）

@猫咬狗 我先描述一下我的方案，关于权限、角色、用户、用户组、部门的定义基本和你的一样，但是有一点不同，就是我不仅需要对模块功能进行权限控制，还需要对当前模块下面的内容进行控制。 举个简单的例子，知识库管理，在知识库管理包含知识库分类（也就是一个树形分类），每个分类节点下面包含多个知识文档（Document）。 系统现在需要对知识库分类的某个节点做权限控制，把这个节点（包含当前节点的下级节点）下的知识文档分配给一部分人员访问。 可以通过上述的角色、用户、用户组等来实现，那么现在系统有一个要求：当用户打开知识库管理菜单时，需要列出当前用户所能访问的文档列表。 也就是说当前权限控制已经不是针对一个权限操作点进行验证了，而是要对一个列表进行验证。 对列表进行验证时我们不可能把所有的数据都取出来，然后一个一个的进行单个权限去验证吧，所以就需要一个复杂的脚本来进行查询

@迷茫的猪 用户登录时就应该把这个用户所有的角色记录在登录信息中，一次会话不应多次查询。 角色对应的权限不会消耗多少性能的，就是个一对多的表，没什么大问题。 最好登录的时候也把权限记录下来，因为访问每个资源时都重新查询这个资源是否可访问也是不合理的。 如果真的是高并发、大数据？（资源能有多少？大的起来吗？）也有很多的解决方案啊。比如在服务器上写xml，或序列化加密后放cookie都行。不过不推荐，资源肯定不会很多。如果1000的资源别人使用你的角色权限分配功能的时候也头大啊，那么你可能需要重新规划你的权限划分了。

最近一直在忙一个系统，里面涉及到复杂的权限分配及资源访问控制。看了您的文章，感觉和我的方案在很多地方都是相同的，但是在实际应用过程中有一个比较棘手的问题： 在知识库资源中有一个子类的知识库，需要对一部分人开放，那么跟据上述方案就可以把这个子类库分配给一个角色进行访问，然后把角色分配给用户或用户组或部门或公司。 那么现在问题出来了，如果一个用户进入系统想查看他能访问的资源列表时，就需要写一个非常复杂的Sql查询语句，对用户的角色，用户所在用户组的角色，用户所在部门的角色及用户所在公司的角色进行查询。 这样一个查询在大数据量及高并发访问时对系统的压力是非常大的，那么各位是怎么解决这样一个问题呢？

分析的相当透彻细化...模拜了

关注

感谢！
但文件下载不了

功能级权限可以通过RBAC策略即可。

复杂的是细粒度的权限管理。细粒度权限按照数据操作方向可以分为：
1，查询权限，从数据库查询数据，要控制到行列级；
2，决策权限，当用户将数据同步到数据库，先判断用户是否具有该操作权限。比如修改某客户资料，删除某客户资料。


好的权限，应该将权限从业务分离出来，而且应该容易实现。Metadmin提供这方面的服务。欢迎浏览 http://www.metadmin.com。

看了你的这个权限系统学到了很多东西。

我也看到过别的OA的权限系统，和你的有很大的相似处，但也有很大的差异

源代码也下载不了!!

--引用--------------------------------------------------
金色海洋（jyk）: 你的这个文件格式是xml的，不管扩展名是什么。
Access文件的扩展名也可以改成.config的，来防止下载（当然可以正常使用），但是他还是Access数据库，呵呵。

<Sql sqlName="GetCity" text="select distinct city from authors" />
<Sql sqlName="GetState" text="select distinct state from authors" />
<Sql sqlName="SearchAuthors" text="select au_id,au_lname,au_fname,phone,address,city,state,zip,[contract] from authors where 1=1">

你的这个例子里面 authors 出现了两次，city,state 都出现了两次，而且还是同一个表里面的。其他的地方可能还会出现。如果字段名有变化的话，改起来就不方便了，谁然可以用查找替换，但是还是很容易遗漏，和勿替换。

放在数据库里面，单独存放字段名，然后做关联就好修改了。
--------------------------------------------------------

我想用宏的方式来解决你说的问题。在还思考ing。。。

@草原上的骏马
是，我也觉得用字段关联数据库确实麻烦。灵活和易用性2个本来就有着不可调和的矛盾，没有谁好或者不好。主要是看具体的项目，但大部分项目没必要做到把字段都存到数据库中。
我是这么想的。

@ 金色海洋（jyk），用数据库单独保存每个字段的话，虽然减少了重复，但是其中的关联关系感觉会比较复杂了。这个平衡感觉不好把握

了解一下……

比较郁闷.反正就是都不会调试

你的这个文件格式是xml的，不管扩展名是什么。
Access文件的扩展名也可以改成.config的，来防止下载（当然可以正常使用），但是他还是Access数据库，呵呵。

<Sql sqlName="GetCity" text="select distinct city from authors" />
<Sql sqlName="GetState" text="select distinct state from authors" />
<Sql sqlName="SearchAuthors" text="select au_id,au_lname,au_fname,phone,address,city,state,zip,[contract] from authors where 1=1">

你的这个例子里面 authors 出现了两次，city,state 都出现了两次，而且还是同一个表里面的。其他的地方可能还会出现。如果字段名有变化的话，改起来就不方便了，谁然可以用查找替换，但是还是很容易遗漏，和勿替换。

放在数据库里面，单独存放字段名，然后做关联就好修改了。

@私家侦探
没用过啊。
spring、dnn、castle、nhibernate都用过。就你说的这个了解不多，有时间去看看。

@私家侦探
肯定有啊。下次贴代码的时候会贴出来的。
我们项目orm用的是AR。datahelper就是用的这个，这些问题一定会考虑到的。

有个疑问,从xml读出的sql有没有缓存啊,每次都要再去读文件不是要s

有没有用过ibatis.net 这个框架呢,它也是把项目所有的sql语句集中在很多xml文件欧

@在路上的牛
--引用--------------------------------------------------
在路上的牛: 用楼主的方法，对付报表的修改有用，改SQL不用重新编译了。
--------------------------------------------------------

呵呵，确实是这样，但当时做这个最重要的是方便部署后调试。我们研发部门和运行部门在两个不同的事业部，交流起来很困难。
还有一点就是数据量的问题，我们公司几万人的企业。非常海量的数据，ORM基本上应用不多。。

用楼主的方法，对付报表的修改有用，改SQL不用重新编译了。

我自己现在的项目中，写SQL的情况基本只限于部分报表和某些对性能要求特别高的地方，所以SQL很少，业务逻辑层基本不见SQL。

@金色海洋（jyk）
呵呵，这个我也想过，当时设计的时候想到放在资源文件里面。当如果把网站编译成单独程序集，你改sql还是需要重新编译。
放到数据库到还真没想到。
放到配置文件中是后缀名字config的，不是xml。这两个可大不一样，xml是有办法下载下来的，但config是绝对下不下来的。跟webconfig一样，要是webconfig都可以下载下来，那系统还存在什么安全性呢？

http://www.cnblogs.com/jyk/archive/2008/07/28/1255101.html

http://www.cnblogs.com/jyk/archive/2008/07/26/1252212.html

这里有思路。

我的思路和你的有点类似。你是把sql语句统一放在xml文件里了。
而我是把sql语句放在数据库里存放。

其实准确地说，我存放的不是单独的sql，而是模块名、表名、字段名，模块需要的字段，就是关联关系。

比如我有一个新闻管理模块，这个模块需要显示新闻名称，发布时间等字段，那么我就可以记录，模块ID，模块需要的字段ID，然后需要的时候组合成需要的sql语句。

这么做的好处就是，数据库里有一个字段，“配置信息”里面只有一条记录与之对应，其他的地方都是应用字段ID。就是说当数据库里的字段名有变化的时候，我只需要改一条记录就可以了。


你的这种方法，当字段名发生变化的时候，是不是要改好多处呢？

orm不能取代sql。2个互补才是最好的解决方案。我现在参与的项目（千万）采用ORM和sql并存，楼主的想法是可以的，我们没有那么做，我们直接作为查询模板存入数据库（自己写的定制工具），这样就特别简单了 呵呵

@在路上的牛
orm不能取代sql。2个互补才是最好的解决方案。
我不是不认同orm，在项目中也经常用。
但绝不是有了他就不用自己写sql了。那你开发出来的东西将会很可怕。

感谢分享
辛苦啦，呵呵

阅读代码的时候都要对照这个CONFIG，有点不方便啊。最好是采用ORM，能消灭95%以上的SQL，代码也好理解好维护。

@addday
你的那个父id列表是什么样的储存格式？sql2005提出了一个专门解决树形结构的方法。虽然也是老酒新壶，但最主要的是他提供了很方便的由原来的父id转到新方法的函数，我叫这个方法为全路径节点，微软叫什么我不记得了。不过确实很不错。


难后你说的那个树型结构的资源分类，其实和我做的那个差不多。
就比如我是把一个页面当成一个资源，通过读、写、删除等访问模式组合成权限赋给角色。
而你是直接把这个资源变成的权限，叫做A页面的读资源、A页面的写资源、A页面的删除资源。然后再加上了树结构，用于分类管理。
你觉得这样数据库简洁，我觉得我那样做资源管理更清晰，没有谁好谁不好，看实际项目吧。

@猫咬狗
利用树型结构的资源分类，可以组合出字段，操作等等。减少设计的复杂性。

@addday
看看先，大家可以一起讨论，慢慢去完善他。

http://addday.javaeye.com/blog/221607

参考了你的设计，写的。

@斧头帮少帮主
1.使用forms验证登录后就会true啊。
2.跟session不一样。
3.关闭页面在打开，你可以设置，是否记录，记录多长时间。也可以退出时自动清除。

4.
//登录且跳转到原请求页面，如果没有。将会跳转到默认页面。
UserInfoBase.RedirectFromLoginPage（用户名,是否保存密码,要保存到cookie中的data)；

HttpContext.Current.User.Identity.IsAuthenticated
在何时赋值为true?还有这东西跟Session一样一直保存这么?关闭页面在打开该值还保存登录状态吗?
一直没用过User.Identity.IsAuthenticated的说.

你的登录代码里没有啊
protected void Login1_LoggingIn(object sender, LoginCancelEventArgs e)
{

string userData;

//先到数据库中去验证。顺便取得需要放入cookie的信息。

//然后登录。
userData = "用户信息，序列化后的字符串";
UserInfoBase.RedirectFromLoginPage(Login1.UserName, Login1.RememberMeSet, userData);
}

谢谢!请有时间了回复一下为我扫盲.

你可以发给你的例子给看下不，我按你的方法做了，不过还有一些不太明白　QQ4280QQ@126.com

--引用--------------------------------------------------
猫咬狗: @northdevil
他不好用，你可以自己做几个例子看看。局限性很大，对部署也有要求。
--------------------------------------------------------

可否举一些局限性和部署要求的例子?

@northdevil
他不好用，你可以自己做几个例子看看。局限性很大，对部署也有要求。

@向心力
呵呵，是啊，但我的目的是规范。在项目中我但用这个方法限制脚本注册，而且所有文件的路径全部都放在资源文件中。这样更好管理。

用户控件中,可以用ResolveUrl来解决路径的问题
<script src='<%=this.ResolveUrl("~/abc/def.js")%>'></script>

System.Web.Configuration.AuthenticationMode.Forms == AuthenticationMode.Forms

采用Forms验证后,在没登录的情况下去访问需要验证的页面,Asp.net不是会自动重定向到登录页吗?还需要自己再写这段代码干什么呢?
另外,也可以通过
<location path="Test.aspx">
<system.web>
<authorization>
<allow users="?" />
</authorization>
</system.web>
</location>

来标记哪些页面不需要验证啊

@啊
这个还真不好说啊。
在框架页中session通常无辜丢失。
session时间长了会失效。
记住密码功能还是要自己写cookie。

还是那句话，没有绝对的好或者不好。看你自己吧。我就是喜欢用Forms验证，有人能我说不对吗？就像你就是喜欢用session，谁敢说你错啊。

session又有何不好呢？

@猫咬狗
同感，我觉得membership就是一个标准的鸡肋，食之无味，弃之可惜。

@Gray Zhang
其实我觉得很多时候系统设计是在找一种平衡，没有绝对的好或者不好。我们经常会在需求、实现、安全性、可扩展性等等等等方面找到一个适合自己系统的平衡点。我只能说我现在的这个系统适合我写的这个东西，但绝对不敢说Membership不好。
是不是看的有点飘？ ：）

再说你的提出的问题：我觉得Membership和我做的这个根本不是一个东西嘛。Membership是对帐号的管理，包括什么身份验证啊（但不会自动登录，login控件是通过membership验证后由控件登录，Membership不会登录滴）、找回密码啊、用户注册啊。====对帐号的管理，我做的是登录验证。自动登录验证。可设置到页面级别的自动登录验证。

既然说到了Membership就干脆多说点吧。再次声明，这是我个人以为，你完全可以说我不懂Membership全是乱扯。只能做参考，千万别当真。
Membership有这么几个功能。
1.创建新用户和密码。（我讨厌他的数据库，自己做表或者和他现有表整合还有重写provider，放弃。）
2.将成员资格信息（用户名、密码和支持数据）存储在 Microsoft SQL Server、Active Directory 或其他数据存储区。（我们用的是Forms认证，到头来还是需要手动添加票据到cookie中。这个功能相当于没有。）
3.对访问站点的用户进行身份验证。（就是你说的那个ValidateUser，还是要重写。哎。。。。命苦啊。。。）
4.管理密码，包括创建、更改和重置密码。（我要做个QQ一样的密码保护功能，还要号码申诉了，你能做到吗？还是要我自己写。。。）
5.公开经过身份验证的用户的唯一标识，您可以在您自己的应用程序中使用该标识，也可以将该标识与 ASP.NET 个性化设置和角色管理（授权）系统集成。（不就是说大家可以通过一个方法得到当前登录的用户，这个用户还可以和微软自己做的那个profile集成吗？没这个需求，不要他。）

写到这里我还真的有个自己写个通用membershipprovider的冲动。再议吧。。

想问一下，直接使用Membership有什么不好呢？自定义一个MembershipProvider也很方便的吧，只需要ValidateUser一个方法

我对session是彻底伤心了
***********************
可以说得具体点吗？

@简单就好
下篇马上写好。请关注，谢谢。。。

@猫咬狗
真希望你能把那个框架发过来，我觉得写的真不错，我都好好看来一下。多谢