思路是可行的,但设置“用户(或角色)<--->URL”对应关系比较麻烦,
还有个控制粒度问题不好解决,比如,某个页面上有增、删、改操作,
就不能控制到具体 增、删、改操作上了,除非每个页面只做一件事......

解决方案 »

  1.   

    同意二楼的意见
    我以前也用的对应url的
    但是太麻烦了
    而且有很多缺陷
    比如,具有管理用户页面权限的用户,就成了终极用户,什么权限都能有upup!
    请高手们帮忙啊
      

  2.   

    我也就要涉及这个问题了,目前的粗浅想法是,各种操作都保存在数据库中,并指明执行此种操作所需的权限,比如删除合同所徐全县为9,而登陆用户的权限为8就不能执行这样的操作。
    再比如表单内部的修改、删除等也按照这个方法进行。
    我过去在bcb中这样实行,挺好的,不指导再jsp中怎样。
      

  3.   

    分析说明
    v 每个用户在系统中由一个唯的USERID标识。 
    v 用户通过系统登录界面登录系统,系统通过加密算法验证用户身份和判断用户是否已经登录系统。如果登录成功通知Application preference service和安全管理系统保存用户登录信息。 
    v 角色由用户根据自己的设想的组织机构进行添加设置,提供一个专门的模块用来设置组织机构,用户通过组织机构(定义?部门机构还是后面提到的"机构是实现和执行各种策略的功能的集合")方便地进行角色管理。例如:用户可以通过部门机构来进行角色的管理,部门采用编号分层的方式,编号的每两位为一个层次。例如一级部门编号为两位,二级部门编号为四位依此类推下去直到将全厂部门机构建立树状结构图。这类数据仅为方便用户管理角色而存在,在系统的其他方面不存在任何意义。 
    v 每个角色在系统中也是由一个唯一角色编号来标识,同时必须保存用户所设置的机构信息,一般来说每个角色只需要保存自己所在机构的代码即可。
    (二)菜单控制
    需求
    此菜单乃系统业务功能菜单。由业务功能模块列表和用户菜单定制共同组成。每个用户可以拥有自己的菜单,也可以直接采用角色缺省菜单(当用户同时充当多个角色并且权限重复时,重复的权限仅一次有效)
    分析说明
    v 为了方便用户进行权限组织管理,需要在系统中建立一张业务功能模块列表,在用户界面上表示为树状分层结构。 
    v 业务功能模块以用户定制菜单来体现,仍然采用编号分层方式,编号的每两位为一个层次。并标明一个层次是子菜单还是业务模块,子菜单只有一种可否被访问的权限设置,业务模块权限由系统管理员或授权用户进行设置。对每个业务模块设置它的对象控制、记录增删改控制和记录集控制。当用户拥有对业务模块的某一权限时,必需对处于它上级的子菜单有可被访问的权限。删除某一个级子菜单时将提示用户他的下级菜单与功能模块都将被删除掉。 
    v 当用户同时充当多个角色并且权限重复时,重复的权限仅一次有效,用户拥有他充当的所有角色的权限的并集。 
    v 用户与角色拥有的系统权限查询时以业务功能模块列表的树状结构显示出来。 
    (三)对象控制(现在未到达此阶段)
    需求
    对象是指应用系统窗口中的可视对象,如菜单项、按钮、下拉列表框、数据编辑控件及数据编辑控件的字段等。对象控制通过角色与用户授权来实现。
    对象控制包括对对象属性的控制可对数据编辑控件中的数据记录的维护权限:
    v 对象属性:使能/禁止、可视/屏蔽 
    v 记录维护:增加、删除、修改的组合 
    分析说明
    v 将每个业务模块可进行属性设置的对象由程序员事先设定或由售后技术支持工程师指导用户加入。 
    v 在系统管理员或授权用户进行设置业务模块的每种权限时,设置用户在拥有该业务模块这种权限时的对象属性。没有设置属性的对象在保存对象信息的时候,用户权限信息中不被保存。 
    (四)记录集控制
    需求
    记录集的控制是通过条件设置来实现,因此,需要控制记录集的数据库表需要设置专门的记录集筛选字段,而筛选条件由用户根据岗位自进定义,建立过滤表,统一管理。
    分析说明
    1. 在对用户设置业务模块权限时,同时在过滤表中设置本模块的数据编辑控件的数据筛选条件,筛选条件是组成SQL语句的WHERE条件子句迫使当前访问的模块根据筛选条件对数据编辑控件的SQL语句进行重组,并检索数据。 
    2. 当存在需要从数据库中多个表取数据的情况时,过滤表中存在多条记录,每一条记录记录一个数据编辑控件取数的筛选条件。 
    3. SQL语句的WHERE子句的生成与校验可以通过的SQL语法分析服务,利用对象所提供的函数分析SQL语句,截取WHERE条件子句,校验新组合的SQL语句的合法性。
    (五)权限分布管理
    需求
    上述提到的权限管理内容应该满足既可集中管理,也可分散管理的目标。
    分析说明
    1. 权限管理由系统管理员集中管理,系统管理员工作负担过大,难对所有岗位的分工有全面和具体的了解,对权限作出标准细致的划分,对于大型的管理系统适合于把一部分设置权限的交由一些比较高级的用户来进行,有利于各岗位细致协调的工作。这就是权限的分散管理。 
    2. 要实现权限的分散管理,就须对授权模块进行一些授权管理,这要求整个系统的授权安全管理工作要做到细致,不要出现权限的漏洞使一些高级用户拥有过大的权限。
      

  4.   

    这里是一个在Java Web项目中用户权限的实现方法:
    http://www.infoxa.com/asp/book/xxnr.asp?id=1333
    《Struts开发实例》"如何建立一个带登陆页面及角色的Struts数据库应用程序"
    摘要:
    ....
    上面的数据,一个用户可能有一个角色,也可以有多个角色。对于多个角色,可以用多条记录来表示,一条记录表示一个角色,也可以用一条记录表示多个角色,每个角色用“;”来分开。
    ....
    上面是用<app:checkLogon role=“system”/>标签来检查用户是否已登陆以及用户是否含有role属性指定的用户角色,这里只能放置一个角色,如果要放置多个角色,如何处理?....
    其它非常简单。只要对上述程序进行如下改进就行了:
     标签用<app:checkLogon role=“角色1”; “角色2”; “角色3”/>这种方式表示。每个角色用“;”分开即可,表示只要登陆用户有这个role属性指定的角色之中的一个角色即可通过。
      

  5.   

    myy() 
    思路是可行的,但设置“用户(或角色)<--->URL”对应关系比较麻烦,
    还有个控制粒度问题不好解决,比如,某个页面上有增、删、改操作,
    就不能控制到具体 增、删、改操作上了,除非每个页面只做一件事......
    ======================================================================
    参数可以解决这个问题嘛,我文中已说了.当然这种权限的管理仅适合网站,不适合像OA这样的系统,因为他不能实现部门级别的权限.
      

  6.   

    to pcdll(.net) :参数可以解决这个问题嘛,我文中已说了.当然这种权限的管理仅适合网站,不适合像OA这样的系统,因为他不能实现部门级别的权限.
    ======================================================================用参数当然可以。我不是说不可以解决,只是太麻烦,因为参数很多都是动态的,
    很难做到既灵活又简便...
      

  7.   

    用filter呀
    ============================================================filter只能作为权限判断的手段,而且也有许多缺陷,比如,你得“放过”
    许多一般不需要判权限的访问,如.gif、.jpg、.js...等等,甚至“登陆”等
    页面也得“放过”,否则无法登陆。也许你会说,我只拦截.jsp作权限判断,那servlet呢?
      

  8.   

    filter可以配置来限定某个目录的访问权限
      

  9.   

    请问各位有相关的例子吗?
    谢谢了
    [email protected]