标识
权限
因为后台的访问控制都是基于Action级别 的控制,而我们使用系统都是以功能模块为最小单位的控制,所以我们首先需要建立一个Action和功能块的对应关系,如:“创建用户”功能对应的Action是“Create”。由于开发人员的差异有时候这种对应的关系很难得到保证。应该避免一个Action操作多种功能,这对与基于Action级别的访问控制不利。一般不存在一个操作对应多个Action。这样我们建立的Action和功能映射表就是一一对应的了,完全可以使用Controler+Action的名称来作为功能的权限标识,但是我们经常有出现重载的Action在GET和POST请求中,所以我们最终使用Controler+Action+RequestType。
接下来,我们需要将角色和功能关联起来。这样在权限树中,我们以中文描述,实际以其权限标识和角色标识关联起来。
数据库设计
流程图:
后台访问控制
在首次验证用户名和密码时,应该将该用户所有的角色的权限的标识无重复的存储在该用户的Session中。有时候为了避免多表查询带来的性能问题,我们可以在用户表中冗余的存储其所有的权限标识。
我们将所有需要权限的Action都使用扩展了过滤器的的属性标识,这样在执行Action之前就会验证用户的权限,通过获取用户当前访问的Controler和Action名,查找保存到用户Session中的权限标识集合就可以确定其是否有访问权限了。
视图访问控制
我们虽然在后台功能访问上做了决定性限制,但为了用户体验度,我们还需要控制视图级的功能显示和隐藏,用户没有 权限的功能块,不应该显示在当前用户视图中。这个在MVC中,只能通过在视图中写if...else...来判断了。至于判断的条件还是功能的“权限标识”,看当前用户Session权限标识集合中是否存在即可。
身份验证-双证模式
参见“双证模式”。
票证:我们设计一个独立票证发放类,提供简单和安全两种票证生成方法,简单票证可以易于受到“会话劫持”攻击,但生成效率高,使用GUID即可。使用安全票证,就是将变数大的随机信息,如用户浏览器和IP、时间、随机数等信息作为产生票证的参数,同时在服务端Session中保存其浏览器、IP等客户端信息,以便核对用户的浏览器和IP信息是否一致,如果不一致说明此请求为黑客“会话劫持攻击”行为。
密码加密:使用标准的MD5加密策略,MD5“雪崩效应”高,且不可解密。只有在极端情况下使用超级计算机通过“碰撞”才能解密。普通计算机几乎不可能产生有效碰撞。(
更正:2005年王晓云教授已使用普通微机就能在短时间内产生一个有效碰撞。估计可以使用SHA-2了。)
为提高性能,以上两个类使用“单例模式”。
关键代码: