web开发中的权限设计拙见一二(1)----设计思路

最近项目的项目很奇怪，一个大项目(系统)里包含了很多小的子系统，而这些子系统中都有权限控制的部分，这件事情挺让我头痛的，记得一年前在沈阳，我曾经有一段时间也因因这个问题而疲于奔命，为什么说疲于奔命呢？由于当时项目进度不允许，导致最终系统权限模块草草了事，每个模块都是由读权限字符串来控制用户ACL，当用户无法访问时，提示权限不够。这么做对用户是很不负责任的，既然让用户看到了操作的方式和界面，为什么又告诉用户没有权限呢？我开始怀疑我们是否应该在底层就封杀用户的访问权限。

现在项目开展起来了，虽然目前我已经有了对权限控制的一套方案，并且实施成了我的可重用框架代码，虽然目前的权限也是基于众星捧月的AOP思想，但我至今对权限设计仍有两个疑惑：

疑惑一：很多同行提出方案，想要在底层就截取用户权限，控制用户对方法或者类的访问。这样做的好处在于可以将系统功能与业务逻辑松散耦合，并且实现简单，结构清晰，三两个advisor、filter，或者acegi就能搞定，但在web程序中体现出了他的劣势，当我们将用户的访问拒绝在业务逻辑之外的时候，我们此时是否应该抛出异常提示用户？一旦提示用户没有相应的权限，我认为对于用户来说，这就不是一个perfect practice。由此得出，我们根本就不应该让用户做此次操作，而控制用户操作的源头就是界面，也就是说，在界面上我们就应该对用户的权限元素(如添加按钮、功能菜单等)进行控制。此时，一对矛盾出现了，要控制界面上形形色色的元素只有两种办法，一，将权限与你的界面结合起来设计，这将违背AOP的思想，也使得系统控制模块的重用性大大下降，二，我们借鉴primeton的想法，将权限控制的理念抽取出来，单独做成一套权限系统，解决你所有的需要权限控制的系统需求，这样也有令人头痛的问题，你的所有想用它来控制权限的系统，必须界面上统一风格。或许这样的方式对商业web系统是合适的，毕竟需要你大刀阔斧个性化的地方不多，但我们却很难保证在未来几年内商业web系统的风格不改变。再者，开发这么一个系统也不是一蹴而就的事，在这个问题上一直让我困惑不已。

疑惑二：大多应用的权限判定是基于权限字符串的，但存储在数据库中的权限字符串能够判定的权限并不多，在我们这次项目中，我引用了基于二进制的8421权限判定法则，我深深的感觉到权限字符串的弱势，这使我想起了中国古老一套数学理论-“盈不足术”，超递增序列的魅力在我眼前滑过，

首先我来解释一下盈余不足理论：有十只盒子，第一个盒子里放一个盘子，第二个盒子里放两只，第三个盒子里放四只，第四个盒子里放八只……第九个盒子里放256只，第十个盒子放512只，即第N只箱子里放2^(N-1)只盘子，一共1023只。那么命题如下：在1023这个数字之内，任何一个数目都可以由这十只盒子里的几只组合相加而成。那么1、2、4、8、16、32、64、128、256、512这个序列为什么有这么个魔力？这个数列的特点：1、每项是后一项的二倍，2、每项都比前面所有项的和大，而且大1。这个1就是关键，就因为这个1，它才可以按1递增，拼出总和之内任意一个整数。这个序列叫做超递增序列，它是解决背包问题的基础。3、拼出总和之内任意一个整数可以由这个序列中的一些数构成，且构成方法唯一，据说是密码学中的NP定理。譬如说这个数列总合中20这个数，只能由16+4一种方法构成，由此延伸出来，如果综合中这个数据代表一个权值，我们可以解出它的所有构成参数（操作），如20这个数据，我们可以挨个和序列中每一项按位与，得出来如果不等于0，就说明他是由这个数构成的。

保存权值到int还是varchar对于我们来说是个问题，当然，保存字符串的好处是运算压力小。我们可能听过一个故事，就是把这个超递增序列延伸到第64项，就是那个术士和皇帝在国际象棋棋盘上要米粒的传说。64项的和是一个天文数字！但计算机本身就是一个只认识二进制的机器！很多程序员整天只关心架构，甚至不知道或者不关心位操作是什么玩意，当然我们有朋友担心数据库的int不够长，那么既然可以保存一个只有0、1组成的varchar字符串，为什么不能保存一个十六进制的字符串，有人规定varchar只能保存01吗？十六进制串的长度正好是二进制的四分之一。

由此我们可以无限制的扩展权值操作。

在最近的项目里，我对权限的控制分成两个部分，第一就是用户体验上，我设置了一个权限标签，从数据库中抽取权限信息，然后做到标签里，也凑或算成是界面AOP了，第二就是底层的拦截，用了Spring 的AOP，为的是防止权限冲突，双管齐下。暂时解决权限所需，另外在算法上我用了16进制的权限判别代码，虽然配置较麻烦，写完代码还要写文档说明，不过也解决了权限繁杂又多的问题，暂时就这样了，嘿嘿，以后有空再研究。