解决方案 »

  1.   

    是针对一张表的数据级别的权限过滤、根据条件来做控制说白点其实就是A用户可以查询所有数据,
    B用户只能查询B单位的数据
      

  2.   

    楼主这个不就是条件的值是固定的,也就是规定了这个用户的筛选条件值必须是这个。可以把用户和查询表的固定条件值放到xml中,楼主可以在数据访问层做拦截,这个可以借鉴hibernate的hql转成sql的实现,在sql要执行前要对sql进行分析,可以用indexof的方式取出from 后面时候有xml里面配置的特殊查询表有用到的就在where条件后面添加上其在xml里面的固定筛选条件
      

  3.   

    上面可能说错了,不是针对一张表,是针对一个菜单功能一个功能可能还设计到多表查询,
    select a.xxx,b.xxx from a,b如果根据菜单配置的话,那么首先菜单是配置的http://localhost/a/test.do
    之前有想过,根据表名称,查询出这个表有哪些字段,然后配置字段的条件,
    但是这个test.do是不知道要查询那些表的,一般都是调用dao层写死的sql语句
    那么他所查询设计几张表,这个就不知道了,就没办法配置,
    如果再配置一层一个菜单,把相应的表再另外写一个功能配置上,
    那样感觉比较死,也比较傻
      

  4.   

    楼上的意思,我大概明白,
    但是筛选的条件值是不固定的,
    假设一张表、
    我给A用户可以查询这张表单位是101的所有数据
    我给B用户可以查询这张表是时间短在2014-5-1至2014-5-30号的数据
    我给C用户可以查询这张表的创建人是A用户的
      

  5.   

    楼主这个就是菜单的权限吧,每个角色的到菜单里面看到的数据都是不一样的,其实不管哪个用户进这个菜单其对应的sql已经是写好的了,只是要根据不同的角色权限加上特定的筛选条件是这样吗
      

  6.   

    楼上给的都是 rbac 了,这个适用于等级权限系统。数据级的话,rbac 的粒度不行的。
    可以考虑范围限制权限系统。
      

  7.   

    可以参考 Linux 文件权限系统
      

  8.   

      建立一张动作表,再建一张角色动作表。动作表包括你先要用户所能控制的动作
        然后,再建一章角色动作表,就是角色id和角色下有那些动作id,多个动作用字符串拼接(1,4,7,9)
     然后用户每次登录后根据用户ID查询有那些角色,再通过角色id操作下角色动作表,根据动作id将所以的动作分割出,
    再来查询动作表,装入List容器,如果有模块的话,一般是角色下有多个模块,模块下有多个动作。这样来操作
         你最后建个模块表,一个区域一个模块,比如书,游客只能看书,管理者可以上传,修改,删除。
       看书是个模块,下面有多个动作,
          最好的方案是,一种资源一个模块,模块下有多个动作,用户操作角色,角色操拥有模块,模块拥有动作。
        
      

  9.   

      建立一张动作表,再建一张角色动作表。动作表包括你先要用户所能控制的动作
        然后,再建一章角色动作表,就是角色id和角色下有那些动作id,多个动作用字符串拼接(1,4,7,9)
     然后用户每次登录后根据用户ID查询有那些角色,再通过角色id操作下角色动作表,根据动作id将所以的动作分割出,
    再来查询动作表,装入List容器,如果有模块的话,一般是角色下有多个模块,模块下有多个动作。这样来操作
         你最后建个模块表,一个区域一个模块,比如书,游客只能看书,管理者可以上传,修改,删除。
       看书是个模块,下面有多个动作,
          最好的方案是,一种资源一个模块,模块下有多个动作,用户操作角色,角色操拥有模块,模块拥有动作。
        你说的这个还是基于功能权限级别的,像你说的动作级别的控制,已经实现了,
    现在想要的是单表不同用户显示不同的数据。
      

  10.   

    hibernate filter,强制用hql,这样每个实体就能保证拼上需要的hql
      

  11.   


    后台sql的条件怎么拼接,那我其他的功能也要这么实现的话,你觉得这种方式可行吗?
    还要增加一个配置动作副表的界面功能吗?数据来源是在哪,表结构式哪,可通用吗?!
      

  12.   


    动作副表结构  动作附表id,主动作表id,动作名称。
    用户动作附表,用户id,动作表id,拥有的附表动作id;
      比如你进入编辑书本页面时,一般是点击进入书本编辑时,会有动作编辑id,和用户id吧,通过操作用户动作附表,来实现一些个别用户对资源特别处理。
      至于其它功能,想要特别处理就加,不要特别处理的可以不加。在角色模块付权的时候,麻烦点。
        后台SQL,你是单表操作,不需要拼SQL啊。
    后台sql的条件怎么拼接,那我其他的功能也要这么实现的话,你觉得这种方式可行吗?
    还要增加一个配置动作副表的界面功能吗?数据来源是在哪,表结构式哪,可通用吗?!
      

  13.   

    解决问题的办法有两个:
    第一:虽然你的权限是数据级的,但是仍然是属于功能层面的。
    比如查全公司的人员,和查部门人员,这是两个不同的功能。当然就编程方便性考虑,你可能希望把逻辑写在一起共用,但是为适应rbac,你可以用父子类的方法来区分。第二:不考虑权限问题。直接把角色对象和查询语句的WHERE后面一截进行绑定, 动态配置。这样最简单,不过今后的维护就是程序员的事了。