一个客户系统最基本的功能是对客户的创建，修改，删除和查询。实现这样的功能通常是在数据库中建一个Customer表，然后通过程序实现以上基本功能。在一个个人环境的应用中，一个用户可以对所有的客户进行任意操作,基本不存在权限控制问题。在多用户系统中，客户属于一个人或者一群人，而对客户的操作权限也不可能是人人一样。所以需要对用户的操作做权限控制。
这里有必要先对权限控制方式本身做一下讨论，有些系统用菜单进行权限控制，比如"新建客户"，"浏览客户",往往用操作名加上一个资源名代表一个权限，这样的权限控制有一个缺陷，就是一般漏掉了一个资源范围，比如浏览什么样的客户，就没有说明。当然也可以加上，比如浏览个人客户，浏览部门客户，浏览公司客户，但是随着需要控制资源类型的增加，通过不断增加菜单项来进行控制，并不是一个很好的方法。在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者通常应结合使用。
|
