|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-08-03
george_space 写道 sdnasky 写道 george_space, 关键是你们的权限标签保存的不是权限点，而是角色，因此没辙
权限标签就是标识出，这块范围的权限标识就可以了，权限点跟角色的关系交给数据库动态处理就行了 至于有无权限的判定处理，默认处理，表达式，脚本，处理类，各种工具提供选择 你说的标签方式我理解，就是： 标签定义一个ID="helloGirl" => 标签实现类中判断当前登录者的权限列表，遍历权限所管辖的所有页面元素ID，看看是否包含本标签的ID:helloGirl => 如果包含，显示标签body，如果不包含，不显示标签body 是不是这个意思？ 页面标签上的ID 当然需要用权限ID，像你得需求 如果要给另外一个用户使用那么我们就把该权限付给该用户即可，标签实现类里 只要根据权限ID 去查找该权限ID对应的用户，只要有当前用户 就可以显示。 但是这里还是又一个问题。就是这样做违背了RBAC的模型，我引用了ralasafe权限中间件其中一位commiter的话：“主体和资源种类很多时候，权限控制条目则急剧膨胀条目是N（主体）*N（资源），显然需要有针对性的寻找规律进行分解从而减少数目，可以发现的是如果通过定义有限的角色(R)来替代主体授权则条目数量变化为N*R+R*M，显然角色数量是远远小于主体数量的，从而能够达到简化的母的。这就是RBAC得来源”。因此把上面的用户全部换成角色，基于角色的访问控制将很好的防止了权限的冗余 后期维护也方便。 所以基于页面级的权限控制 我们建议将控制点设置为权限ID或叫资源ID，george_space提出的基于规则的命名 这个后期维护起来将会省很大的力气，另外实现类 就根据权限ID去role_privilege表里查找所有的角色，遍历该角色 查找上下文中用户是否在这些角色中。 ralasafe严格按照RBAC模型 并基于策略的模型实现数据集权限。 网址：www.ralasafe.cn 共同关注。 |
| 返回顶楼 | |
|
发表时间：2011-08-03
做个标记，好好看看
|
| 返回顶楼 | |
|
发表时间：2011-08-03
sdnasky 写道 数据模型不是关键，只要保存用户-权限关系就行了
设计上的关键是找到权限控制点 界面级：自定义标签可以实现 URL级：Filter可以实现 后台方法级：AOP可以实现 数据级：良好设计+AOP可以实现 即使没有良好的设计，针对不同需求，在控制点写拦截处理类就行了，只是重复代码的问题 权限的关键是：找到控制点，拦截，然后做你想做的事情 见解颇深。 
|
| 返回顶楼 | |
|
发表时间：2011-08-03
做一个 记号 也好好的消化一下.
|
| 返回顶楼 | |
|
发表时间：2011-08-03
有一种方法是，将页面元素所在的table中数据生成xml文件，在前台用js取得xml文件中的值，然后判断是N还是Y来决定show/不show，可编辑/不可编辑。。。
|
| 返回顶楼 | |
|
发表时间：2011-08-03
受教了~~
|
| 返回顶楼 | |
|
发表时间：2011-08-03
richit 写道 有一种方法是，将页面元素所在的table中数据生成xml文件，在前台用js取得xml文件中的值，然后判断是N还是Y来决定show/不show，可编辑/不可编辑。。。
这个方式，跟我前面说的服务端向视图层传递json数据时一样的原理。 |
| 返回顶楼 | |
|
发表时间：2011-08-03
每个业务系统都有特定的权限管理方法，通用的？好像有点难了吧。
最重要是可以满足当前业务系统的功能设计。 |
| 返回顶楼 | |
|
发表时间：2011-08-03
刚好我下周的任务就是权限。先mark
|
| 返回顶楼 | |
|
发表时间：2011-08-04
最后修改：2011-08-04
我觉得完全可以综合成 [资源] - [角色] - [用户]
只是资源里面的 可以多加一个 type 字段 类型可以是 url ,file 等 这样会不会简化了呢 前天一想写这个玩意 ... 郁闷 http://vb2005xu.iteye.com/blog/1136852 |
| 返回顶楼 | |
