考虑到通用型问题,不建议直接在方法内部判断谁能用谁不能用,最直接的办法就是建立表,一张是方法表t_method,一张是角色表t_role,角色表里可以有n个角色,而每个角色可以使用的方法就是关联t_method里面的方法序号,每次判断用户是否可以执行,先去角色表里遍历该角色可以使用方法的记录,如果没有找到,那么就返回无权操作,否则允许操作
解决方案 »
- 用struts2框架和不用框架的情况下怎么配置错误页面
- 用jdbc更新数据库某表的所有字段问题?
- 关于乱码问题 希望大家帮帮忙啊!!
- 不知道怎么解决的错误
- Tomcat打印的信息输出到指定日志
- end of stream was detected on a read
- 我在整合hibernate和spring之后测试出错
- JBOSS 安装问题。
- 关于Session Bean 与 Entity Bean 的一个问题
- 超难问题!也是最常见的问题!著名的异常:java.net.SocketException: Connection reset by peer: socket write error,难道不能避免吗?
- jboss中EJB关联时出错,请大家指点一下.
- 使用JXL API在EXCEL文件中写入信息,键入回车,在EXCEL中存在为一个小广框,双击EXCEL中的相应信息后才恢复为回车
不然在运行期再判断一个方法能用不能用还有什么意义?先把不同的角色用不同接口声明,然后用一个类实现所有的接口,这样用接口来定义对象引用,每个引用只可以访问,自己接口声明中的方法。
下面是一个例子,你可以参考一下。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();
}
}
目前我们表的设计是这样的,由于功能点分的比较细,可能在每个界面中有若干个功能点;如果按你的方法,可能在运行效率上不是太好flyforlove;
我的设计思想和你是一样的;不过,我们这里的角色比较多(你这里是假定两个),可能十几个最基础的,同时若干个角色可以任意组合(并或交)成新的角色;所以有点麻烦,在此还望请你指导一下
public method_a(){
//调用权限检查方法
if(!check())return;
//做进一步的处理
} public method_b(){
//调用权限检查方法
if(!check())return;
//做进一步的处理
}} public class RoleChecker { //在此方法中封装所有的检查代码
public static boolean check() throws RuntimeException{
return true;
}
}
你的这种方法在对于客户的业务流程不明确的时候是很危险的
对于后期维护也比较麻烦,
角色设计的原则是动态的,可变的
程序中对资源的保护和角色验证因该由容器控制
角色和人员的映射在rdbms里定义
登陆后,容器就维护了此用户的ROLE,并在客户端请求资源时候做出由否权限的判断,有则允许,没有则按照自定义提示活着登陆等一句话:判断有无权限该由容器负责,读取权限并映射,么高效查询判断,那是表设计和方法的问题,放在内存里比从数据库里方便的多,细节就不多说了。
我的问题中对方法的控制是跟用户权限有关系的。
举个实例:
三个客户A、B、C在网上购买商品;对衣服类商品,A在购物车中添加商品,也可以删除,不可以查看;B只可以添加,可以查看;C可以查看,添加,删除;
商品中有衣服类、食品类、生鲜类……等等;
客户对不同种类商品的处理权限也是不一样的
不过
===================
不然在运行期再判断一个方法能用不能用还有什么意义?
=====================
实际的情况是,交付后,要求methoda()对role a 可用变为对role b也可用这是很普遍的:<,客户可不管我们的死活
你总不能再去设计类?!重新rebuild吧对类中方法判断权限,如果是ejb中,到是可以对方法进行脚色判断
若是普通类中,相比把脚色线值抽象到接口并实现,我宁可还是用一个检验权限的类来判断(胖胖的说法)
这样的可以构成,分组权限加字典权限基本可以囊括各类情况变化时候,无非是权限表的增删改查
不说了,开会去了
商品中有衣服类、食品类、生鲜类……等等;
客户对不同种类商品的处理权限也是不一样的-------------------------------------------------------------------------------如果是你说的这种情况,那就是简单的用户权限的问题,而不像你问题中所说的访问对象方法权限的问题了。
这样的话,你就按照hocus(黄金时代) 所说的,要对角色和所对应权限进行映射,而不是在设计的时候,进行对象方法的组合了,因为后期还要对角色的权限进行更改,所以放到对应表里,应该是最具有扩展性的了。
能否给段伪代码?
大致是如此
可以查一下j2ee api,我记不打清楚
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");