这里有必要先对权限控制方式本身做一下讨论，有些系统用菜单进行权限控制，比如"新建客户"，"浏览客户",往往用操作名加上一个资源名代表一个权限，这样的权限控制有一个缺陷，就是一般漏掉了一个资源范围，比如浏览什么样的客户，就没有说明。当然也可以加上，比如浏览个人客户，浏览部门客户，浏览公司客户，但是随着需要控制资源类型的增加，通过不断增加菜单项来进行控制，并不是一个很好的方法。在B/S系统中的菜单控制，有2重意义，一是真正的菜单，没有权限的用户就看不到相应的菜单项，另外一个为了防止用户任意提交信息，在服务器端对用户提交的URL进行检查，看是不是有这个权限。比如对于用户请求的ListCus.do就要先检查用户是否有访问这个URL的权限： public class ListCusAction extends Action{ ... public ActionForward execute(...){ ... //必须提供这样的检查的方法。 PermitUtil.checkPermit(userID,url); list = dao.query(sql); ... } } 另外一种控制办法是对操作和操作资源定义权限，比如用户A可以对客户进行修改操作。这样细粒度的权限控制对程序的扩展性和安全性有很大好处，但实现比前一种费时，下面通过分析说明2种方式的特点。
作为客户系统最简单的一种考虑，是每个用户治理自己的客户。这种请况下，我们通过在Customer表中增加一个用户字段，就可以知道这个客户对应于哪一个用户。如下面的类所示： public class Customer{ PRivate String ctmNo; private String ctmName; ... private String userID; //getters and setters } 那么通过菜单的控制方式，我们认为每个有客户创建权的用户都可以创建属于自己的客户，什么叫客户创建权，就是可以看到和选择“添加客户”菜单项的用户。同时，“客户浏览”就表示浏览属于自己的客户，这样一来，创建客户的用户可以看到自己的客户，并进行操作，我们通过菜单控制权限方式完成了这个需求。需要注重的是：在用户进行相应操作前，我们先判定这个客户是不是属于这个用户，是就可以操作，不是就不可以。如下例所示： public class DelCusAction extends Action{ ... public ActionForward execute(...){ ... //必须提供这样的检查的方法。 dao.checkPermit(customer,userID); dao.delete(customer); ... } } 进行这个判定是出于安全性考虑的，非凡在B/S架构的软件系统中，你无法阻止客户向服务器端任意提交信息。比如用户A不使用菜单，向服务器请求"DelCus.do?ctmNo=No1",而No1属于用户B,假如不进行判定，客户就被删除掉了。所以光靠控制菜单项的显示完成权限控制，并不完整。
现在我们接触一个更复杂一点的需求，就是客户转移，把客户从一个用户，指派给另外一个用户。在上面的实现基础上，只要添加一个接口，改变客户所属的用户，问题也就解决了。如下： public class ChangeUserAction extends Action{ ... public ActionForward execute(...){ ... dao.checkPermit(customer,userID); //改变客户所属用户到newUserID。 dao.changeUser(customer，newUserID); ... } }
每个用户现在可以治理自己的客户，也可以把客户交给别人治理，问题解决得完美。我们再考虑实际的情况，一个客户可能可以被一个用户看，但是不可以被修改或者删除。我们怎么控制这样的权限，加一个菜单项-"察看客户"，用户A可以执行这个操作，但是不可以选择菜单项-"修改客户"，针对每一个动作，我们加了一个菜单项。我们需要控制的内容变得越来越多。再深入分析，可以发现，其实上面的方案已经不能满足需求。 2个客户我们如何知道一个可以被用户A看，一个不可以，出现了一个资源的治理问题，必须有另外的方案来进行这种权限的控制。我们设计一个资源类： public class CustomerResource{ //客户编号 private String ctmNo; //操作类型 private String action; //用户 private String userID; //setters and getters. } 再设计一个资源治理类： public class CustomerResourceManager{ private static List resources; private static void addResources(CustomerResource resource){ resources.add(resource); } //从数据库装载相应用户的客户操作权限。 private static void retrieveResources(String userID){ ... } //检查相应的权限是否在resources中存在。 private static boolean checkPermit(CustomerResource permit){ ... } } 客户端使用类： public class DelCusAction extends Action{ ... public ActionForward execute(...){ ... //必须提供这样的检查的方法。 CustomerResource resource = new CustomerResource(); resource.setCtmNo(customer.getCtmNo()); resource.setAction("DELETE"); resource.setUserID(userID); if(CustomerResourceManager.checkPermit(resource)){ dao.delete(customer); } ... } } 在采用了上面的权限检查方式后，我们可以对每一个客户指定相应操作人的权限，对客户的操作就限制在了操作类型的多少上，基本的有“UPDATE,INSERT,DELETE,LIST,VIEW”等，其余也可以定义“SUBMIT”等操作，具体取决于系统需求。这样的好处是权限控制非常灵活，客户可以作为资源在用户之间自由流动。但是作为一个给用户最终使用的权限系统，这样的却体系不适合于出现在用户权限系统设置里面，不能叫每个用户都去自己指定自己创建客户的操作范围，最好是通过这种方式实现默认的业务和权限设定，满足了用户需求，又屏蔽复杂性。在完整的系统中，基于菜单的控制也是必不可少，这样的方式方便用户使用，也更易于用户理解。 2者通常应结合使用。
