考虑到通用型问题,不建议直接在方法内部判断谁能用谁不能用,最直接的办法就是建立表,一张是方法表t_method,一张是角色表t_role,角色表里可以有n个角色,而每个角色可以使用的方法就是关联t_method里面的方法序号,每次判断用户是否可以执行,先去角色表里遍历该角色可以使用方法的记录,如果没有找到,那么就返回无权操作,否则允许操作

解决方案 »

  1.   

    我觉得还是用接口比较好。我想一个方法能用不能用,应该在设计期就确定下来,
    不然在运行期再判断一个方法能用不能用还有什么意义?先把不同的角色用不同接口声明,然后用一个类实现所有的接口,这样用接口来定义对象引用,每个引用只可以访问,自己接口声明中的方法。
    下面是一个例子,你可以参考一下。interface int_a{
        public void mth_a();
        public void mth_c();
    }
    interface int_b{
        public void mth_b();
        public void mth_c();
    }class cls_c implements int_a,int_b{
        public void mth_a() {
            System.out.println("this is mathod a");  
        }
        public void mth_b() {
            System.out.println("this is mathod b");
        }
        public void mth_c() {
            System.out.println("this is mathod c");
        }
    }
    public class IntFcTest {    public static void main(String[] args) {
            int_a A=new cls_c();
            int_b B=new cls_c();
            A.mth_a();
            //A.mth_b();  无法访问
            A.mth_c();
            
            //B.mth_a();  无法访问
            B.mth_b();
            B.mth_c();
        }
    }
      

  2.   

    Jacky1206:
    目前我们表的设计是这样的,由于功能点分的比较细,可能在每个界面中有若干个功能点;如果按你的方法,可能在运行效率上不是太好flyforlove;
    我的设计思想和你是一样的;不过,我们这里的角色比较多(你这里是假定两个),可能十几个最基础的,同时若干个角色可以任意组合(并或交)成新的角色;所以有点麻烦,在此还望请你指导一下
      

  3.   

    public class ClassA {
       public method_a(){
          //调用权限检查方法
          if(!check())return;
          //做进一步的处理
       }   public method_b(){
          //调用权限检查方法
          if(!check())return;
          //做进一步的处理
       }} public class RoleChecker {   //在此方法中封装所有的检查代码
       public static boolean check() throws RuntimeException{ 
           return true;
       }
    }
      

  4.   

    上一个贴子中的check()方法之前应加上 "RoleChecker." , 不好意思
      

  5.   

    上一个贴子中的check()方法中应加入两个参数 check(String className , String methodName)
      

  6.   

    flyforlove(为情飞) 
    你的这种方法在对于客户的业务流程不明确的时候是很危险的
    对于后期维护也比较麻烦,
    角色设计的原则是动态的,可变的
    程序中对资源的保护和角色验证因该由容器控制
    角色和人员的映射在rdbms里定义
    登陆后,容器就维护了此用户的ROLE,并在客户端请求资源时候做出由否权限的判断,有则允许,没有则按照自定义提示活着登陆等一句话:判断有无权限该由容器负责,读取权限并映射,么高效查询判断,那是表设计和方法的问题,放在内存里比从数据库里方便的多,细节就不多说了。
      

  7.   

    hocus:能否给个具体的做法例子?
      

  8.   

    flyorlove:
    我的问题中对方法的控制是跟用户权限有关系的。
    举个实例:
    三个客户A、B、C在网上购买商品;对衣服类商品,A在购物车中添加商品,也可以删除,不可以查看;B只可以添加,可以查看;C可以查看,添加,删除;
    商品中有衣服类、食品类、生鲜类……等等;
    客户对不同种类商品的处理权限也是不一样的
      

  9.   

    哦,看的不甚清楚,也理解的部很清楚:)
    不过
    ===================
    不然在运行期再判断一个方法能用不能用还有什么意义?
    =====================
    实际的情况是,交付后,要求methoda()对role a 可用变为对role b也可用这是很普遍的:<,客户可不管我们的死活
    你总不能再去设计类?!重新rebuild吧对类中方法判断权限,如果是ejb中,到是可以对方法进行脚色判断
    若是普通类中,相比把脚色线值抽象到接口并实现,我宁可还是用一个检验权限的类来判断(胖胖的说法)
    这样的可以构成,分组权限加字典权限基本可以囊括各类情况变化时候,无非是权限表的增删改查
    不说了,开会去了
      

  10.   

    三个客户A、B、C在网上购买商品;对衣服类商品,A在购物车中添加商品,也可以删除,不可以查看;B只可以添加,可以查看;C可以查看,添加,删除;
    商品中有衣服类、食品类、生鲜类……等等;
    客户对不同种类商品的处理权限也是不一样的-------------------------------------------------------------------------------如果是你说的这种情况,那就是简单的用户权限的问题,而不像你问题中所说的访问对象方法权限的问题了。
    这样的话,你就按照hocus(黄金时代) 所说的,要对角色和所对应权限进行映射,而不是在设计的时候,进行对象方法的组合了,因为后期还要对角色的权限进行更改,所以放到对应表里,应该是最具有扩展性的了。
      

  11.   

    //对类中方法判断权限,如果是ejb中,到是可以对方法进行脚色判断
    能否给段伪代码?
      

  12.   

    ejbcontext.isCellerUser(String role)
    大致是如此 
    可以查一下j2ee api,我记不打清楚
      

  13.   

    The J2EE 1.4 Tutorial Using Programmatic Security in the EJB Tier 
    Programmatic security in the EJB tier consists of the getCallerPrincipal and the isCallerInRole methods. You can use the getCallerPrincipal method to determine the caller of the enterprise bean, and the isCallerInRole method to determine if the caller has the specified role. The getCallerPrincipal method of the EJBContext interface returns the java.security.Principal object that identifies the caller of the enterprise bean. (In this case, a principal is the same as a user.) In the following example, the getUser method of an enterprise bean returns the name of the J2EE user that invoked it: public String getUser() {
       return context.getCallerPrincipal().getName();
    } You can determine whether an enterprise bean's caller belongs to the Customer role. boolean result = context.isCallerInRole("Customer");