用户、角色和权限开发导言最近花了一段时间在做权限开发者一块，从设计到编码，我都全程参与了，对权限开发也有了一个本质上的了解，权限管理作为一个系统最基本也是最重要的功能之一，在一个系统中是非常重要的，今天我就侃大山，聊聊我这个系统的权限开发的一些东西，与大家交流交流。1、系统的原有权限管理模式之前这个系统的权限管理是通过配置文件来处理的，大概流程是这样的，把用户分成多个用户组，然后每个用户组对应着多个用户的id,每次访问页面的时候,都会读取这个配置文件的信息，判断登录用户的id属于哪个用户组，然后在页面判断这个用户组是否有访问这个链接的权限。配置文件的格式是这样的：｛"adm":[1,2,34],"dev":[5,6,1]｝这样会带来什么问题呢？有以下几个：•权限管理混乱，一个用户id可能会在多个权限组中•每次更新配置文件，都要重新上线，麻烦•没有图形化界面，配置权限困难•页面有太多的if判断语句，造成代码可读性差2、新的权限管理开发这里要强调一遍，这个系统数没有用外面流行的框架的，都是jsp加上之前封装的框架来使用的，所以你们可以发现我这个权限开发是没有用到以前用框架开发权限要用到的过滤器，监听器之类的，或者你可能会说，没有用框架也可以用过滤器和监听器啊，因为这是Servlet的东西。在这里我要解释一下，现在市面上的权限管理我个人觉得大致可以分为两种：1.用户进入系统的时候不判断权限，把系统中的所有功能入口都开发给用户，每次用户点击相应的功能入口时，通过链接和用户判断该用户是否有使用该功能的权限，有权限则进入，没有权限则跳转到没权限的提示页面，这种功能一般都是使用过滤器来完成的2.在用户进入系统的时候就判断用户的权限，根据用户的权限开发相应的功能入口，不同权限的用户看到的页面是不一样的。相比第一种来说，这种的好处是可以屏蔽掉用户没有权限访问的功能入口，用户只能看到自己权限所拥有的功能入口，而根本不知道该系统还有什么功能，更有利于保密。但是，如果只是在用户进入系统的时候就判断权限，以后不再判断，那么就会出现第一种情况中不会出现的问题，那就是权限试探，我可以通过模拟地址栏的形式，不断地改变参数(有些提交方式不得不是get提交，所以地址栏难免会带有参数)来达到破坏权限的目的，代码写得不严谨，这个问题就会发生在你的系统上，比较好的做法就是，在每一次访问页面的时候，都重新再判断一次权限。所以本来就不需要使用过滤器的地方又得再使用上了。然并卵，因为系统的特殊性，该系统的权限开发都不会用到过滤器和监听器,所有的权限判断都写在了一个公用页面上，然后再在每个页面上inelude进去,也达到了类似于过滤器的效果，然而，我是不赞成这样的写法的，框架、过滤器能存在，自然有他们的道理，我之前也做过用框架的权限开发，觉得那样更方便，当然，这是题外话了。(1)数据库设计话说刚开始在设计数据库的时候还是碰到不少壁的，因为头脑中还是留存着系统原有权限管理的余威，在最初设计的时候还受到它的一点影响，后来，干脆就不参考以前的权限管理模式了，做出自己的一套出来。用户表(acctUser)字段类型描述idint(11)用户唯一标识，主键acctvarchar(20)账号namevarchar(20)姓名createTimeint(11)用户的创建时间，时间戳lastLoginTimeint(11)用户的最后登录时间，时间delint(1)是否删除，逻辑删除，1为删除，0mobilevarchar(20)用户手机enailvarchar(50)用户邮箱remarkvarchar(200)用户备注角色表(acctRole)字段类型描述roelldint(11)角色唯一标roleNamevarchar(30)角色roleDescribevarchar(30)角色描权限表在该系统中，权限会被精细化三种权限，第一种是导航栏的权限，第二种是侧边栏权限，最后一种是页面的按钮和业务权限，如下图所示导航栏权限表(acctHeaderMenuPermission)字段类型描述headerMenuldint(11)导航栏权限唯一标识，主键headerMenuNamevarchar(30)导航栏权限菜单名headerMenuUrlvarchar(255)导航栏权限菜单URLmenuOrdertinyint(3)导航栏权限菜单的顺序，展示的时候根据这侧边栏权限表(acctSideMenuPermission)字段类型描述sideMenuldint(11)侧边栏权限唯一标...
