老生常談-權限控制的一些話題

權限判斷一向蔸諟大伙儿常谈的话题啦。偶列举一下比较常见的做法吧（注意，是常见的）

数据库端最简单的可能 是会建 权限实体表、角色表、用户表，偶称其为权限基础表、以及三者之间的关联表。

当然复杂一点的有url到权限或者角色的关联表，用以管理url访问的权限控制。

或者一些其他资源与权限基础表之间的关联，总之就是做一些与具体业务挂钩的扩展啦。

 

茬后代代码端，多半会在某一处施加拦截器用以做权限判断吧。

例如用xwork的拦截器拦截action，通过当前用户色角色以及Action的访问url路径 再加上权限实体三者之间的映射关系来判断用户是否有访问Action的权利。

当然也有用AspectJ的方式来实现，不过原理是一样的。

 

在前台页面上，首先说导航菜单这一块儿。后台肯定是有一个导航菜单表跟角色关联啦，不同的角色登陆进来能看到不同的菜单。这不是问题，因为几个简单的迭代就出菜单啦。

 

最麻烦就是业务页面上这一块儿，按钮级的权限控制，真的是很麻烦呢。

很多人怕麻烦，直接省略掉前台按钮级的权限控制，如果你点了你不能点的按钮，就给个提示说“你不够格”。

 

但理论上，应该直接屏蔽掉这个按钮是最好的，但是应该怎么做呢？

硬编码，偶肯定会被人说菜菜啦。

 

偶目前想到的是用tag的方式。但使用范围太窄了呀。并且，一旦用了tag，前台页面就依赖于这个tag了，换句话说，以后要是决定不用tag了，还很麻烦滴。再者，在我的tag还没出来以前，人家做业务的就没法动手写页面了。因为写了以后还得改，这也是偶不想看见的。

 

有没有类似于AOP一样的无侵入式的方法，能够很优雅的解决视图层的权限控制的问题呢？偶想虚心学习哦

我们来自火星。。。

能不能不要用火星文？


还有，你那个什么无入侵日志。


本来注解的入侵就够大了，要不是注解能提高开发效率，怀疑没有用它的理由了。

你这里还加个@ ，下面的代码明显被入侵了，还说无入侵。你这个最多算个GOOG好主意，而并不是传说中那个根本就不存在的无入侵。

@Log("插入了一个新文档${params[0].id}");  
public void addNewDoc(Doc doc){  
  //  
}  

用XWORK的拦截做权限拦截也很扯淡，你这样一来会导致你ACTION膨胀的厉害，还有就是你的SESSION膨胀，要不就是你做成无状态的，访问数据库。这样一来，你用户一多，你的系统性能可想而知。说不定DOWN机也是很正常的，权限这东西先考虑好你的分层，再来谈吧，本来这东西就是你系统设计的问题。

PS：我很讨厌你的火星文，还有火星语。

url判断就可以了

写一组像二进制的编码，例如 0000000 这样的，分级控制

非主流入侵?  看来咱都老了.

阅读困难，呼吸困难。。。
权限控制到每一条SQL的执行，应该就差不多了。。。

我们是将每一个事件编一个号码
然后将事件分配到角色中去，缓存到内存中，即使判断否有这个事件操作的权限
不知道大家有没有更好的办法，学习中~~~

严重BS楼主的火星文，对NC式的90后不抱认可。

Javaeye里的都是老男人啊。
谈技术就就谈技术，非要影响别人的兴趣
心眼太小
用火星文就跟你穿衣服一样，你不喜欢传大红袍，还不让别人穿啊。