因为今年上半年要对以前的一个系统进行升级，要根据用户或者角色的权限把一些菜单隐藏起来，如果使用Struts Menu的roles的话，则角色是写死在代码里面的，就是"硬编码"(hardcode)，而且这里的角色是Application Server上配置的，在Tomcat上配置还算简单，在WebLogic等大型的服务器程序上配置，必须使用他们提供的Console软件，否则，要自 己写好几个文件，比较繁琐，而且这些角色是在安装是就指定的，如果用户以后想添加新的角色名字，还要修改应用服务器的配置文件（不管是手工，还是代码处 理）。

      如果你的系统负责处理权限，如生成用户、角色，还要为角色、用户指定有操作哪些模块的哪些操作，一个系统很可能有几十个或者上百个角色（往极端情况去想， 呵呵），那么如果能够动态的控制显示哪些菜单项是我们系统中必须解决的问题，而Struts Menu完全胜任这样的要求，具体实现可以参看Struts Menu的下载文件中的文档，需要重点看的是http://demo.raibledesigns.com/struts-menu/dynamicMenu.jsp(动态构建菜单结构)和http://struts-menu.sourceforge.net/security.html（这 篇文章我视而不见，以为没有用处，谢谢倦兔的提醒，^_^）。这两篇文章的用法是独立的，并不一定都要实现，如果你的菜单项是固定的，短期不会有所变动， 那么可以写死到配置文件中，然后用第二篇文章中说的那样，写一个类，实现接口PermissionsAdapter，isAllowed方法中传入菜单项 的名字，然后决定是否显示该项菜单，

       String[] menus = request.getParameterValues("menuNames");

       注释：menuNames是从数据库中读出的记录的集合（数组），你也可以用其他机构，

       然后放入使用request.setAttribute("menuNames",   String[] 变量)  放入request中。

       PermissionsAdapter permissions = new SimplePermissionsAdapter(menus);//menus是菜单名字的数组
       request.getSession().setAttribute("YourAdapter", permissions);}  //"YourAdapter"随便起的名字，
       //但要和配置文件中的permissions="YourAdapter""部分的一致。
     

      在里面添加permissions="你的类名"(上文中是"YourAdapter），如果此处的perssions的值为 "rolesAdapter"，则Struts Menu不会从寻找你的Adapter类了，而是直接创建一个RolesPermissionsAdapter实例，然后使用这个实例处理角色(根据配置 的rolse的角色名字判断是否显示菜单项)。其实PermissionsAdapter是RolesPermissionsAdapter类的一个具体 的实现，如果你不写自己的适配器，则Struts Menu使用自己的这个适配器处理菜单显示。

      后一篇文章的最后还举了一个过滤器实现上述功能的例子，你可以参考一下，这个试验并不是完全由我实现的，是由倦兔提供思路和文档的URL，我只是把思路整理一下，让其他同事实现，我把它记录下来，以免以后再看的时候忘了。^_^

      另外，我还发现Struts Menu的例子里面还有关于Tab页的实现脚本，如果我早点发现它，我就不会在上一个系统中每个JSP页面都嵌入一大堆同样的Table垃圾代码了！！！

      另外，这种做法并没有完全实现控制用户操作的作用，因为用户只是不能看到某个功能的菜单链接而已，如果，他记住了有操作权限的人员操作时发出的请求的 URL，比如:http://rabbit8.blogchina.com?edit?method=delete&sid=5，那么，他就可以 手工输入URL，同样可以删除、修改、查看某些他不应该看到的东西，这有些属于Web安全方面的东西了，呵呵，如果想实现更加完善的权限管理功能，还应改 在执行操作前进行用户身份和权限的验证，从而避免上述方法的攻击或者破坏。如果你对这方面的内容感兴趣，可以查看一些相关书籍，如《Web安全大曝光》、 《J2EE安全大曝光》系列，我春节期间看了这2本书，对于跨站脚本攻击还不太明白，如果哪位明白，请不吝指教，谢谢！^_^

前一段时间我曾专门阅读过一些关于JAAS的资料，网上这方面的资料不多，篇篇文章都是侧重于讲述一些核心的JAAS类（不过讲的蛮不错的，呵呵。。。对于这方面的入门极好），而对于应用方面给我的感觉就像：

“天啊，几乎没有人用到它~！”

还好chinaxp论坛的源代码中涉及了这方面的应用，而且它们就是那样做的，这其中给了我不少启示。

目前在我参与的一个项目（正在开发）中，我采用JAAS的验证机制（其中的授权部分因为没有非常熟悉的掌握所以暂时没有采用，而暂时采用另外一种方法来解决，这种方法再接下来的部分涉及。）

先说一些我以其为背景的这个项目：

它算是一个比较大的项目（省级高速公路路政工作平台），大的划分可以分为10个大模块26个子模块，具体分为基本信息维护、路政案件、路政审批等等大模块；权限主要是（对某一模块的维护、浏览以及打印等）

经过讨论我们在设计权限的时候是这样考虑的：

分为三个“角色”：用户、用户组、权限；

他们的关系为：用户属于某个用户组；权限下放到用户组。（这一切都是和“当场客户代表”共同讨论决定的。）

如下表是权限的内容：

rightID
 rightName
 
00100
 维护基本信息
 
00101
 浏览基本信息
 
00500
 维护路产信息
 
00501
 浏览路产信息
 
……
 ……
 

其中系统模块用xml配置，如：

module_config.xml

<?xml version="1.0" encoding="UTF-8"?>

<module-config>

    <module>

        <name>维护基本信息</name>

        <right>00100</right>

    </module>

    <module>

        <name>维护路产信息</name>

        <right>00500</right>

    </module>

……

</module-config>

(采用单例模式在容器启动的时候进行解析)

把具体的权限绑定到每一个*.do请求：

request_source.xml

<?xml version="1.0" encoding="UTF-8"?>

<request_source>

    <request>

        <url>useradmin.do</url>

        <desc>显示用户信息维护主页面</desc>

        <right>00100</right>

    </request>

    ……

</request_source>

（也是在容器启动的时候解析并放到容器中）

系统中权限流程控制基本上我把它分为两个步骤：

1．  利用filter以及JAAS来进行非法用户的过滤

其中所有的*.JSP也要通过*.do来引导，这样就能确保整个系统中没有权限“盲点”，也即可以保证每一个*.do都是“干净的”。

这其中涉及到以下几个文件，具体的代码在此不给出：

（1）iRoadLogin.config

IRoadLogin{

     com.ifreeway.iroad.security.DataBaseLoginModule required debug=true;

};

这个文件在创建LoginContext对象的时候根据这个文件来确定该加载哪个LoginModule对象。

（2）ParseRequestFilter.java
对每一个请求进行非法用户的过滤。

（3）DataBaseLoginModule.java

（4）SimpleCallbackHandler.java

  上边的几个类的介绍涉及过多的JAAS核心类的内容，建议阅读下面连接的内容：

 http://www.yesky.com/20030114/1648365.shtml这篇文章对于你了解JAAS绝对有帮助，你也可以通过我的站点来阅读更多的JAAS资料： http://plateau.sicool.com

2．     2. 在确保是合法用户（已经通过1。的过滤的用户）请求*.do的时候再来判断该用户是否拥有请求该do的权利。
可以在每个action的父类BaseAction中创建一个方法来判断是否合法，如：

        public Boolean validateRight(String _request_do) throws ErrorRequestException{

         //取得user所在的组:a

         //根据_request_do,假设其为：useradmin.do

         //获得其所在的组:b

         //然后根据两次组(a 和 b)是否是同一组来判断该请求是否合法

         //此时的a和b都是很容易在容器中获得的，不会损失效能。

}

前提：项目中的又一个公共的BaseAction，其他的action都要继承它。这一点我想使用struts开发项目的开发员都是很容易理解的。

如：有一个UserAdminAction.java

那么在这个执行它的时候首先调用validateRight(“useradmin.do”)来进行权限判断，如果返回false，那么跳转到error页。

其实我上边所写出的解决方法在我现在的项目中是够用的。是谁说过：“够用为原则”？项目的权限设计这部分实在是个非常大的讨论题目，这里算是抛砖引玉，希望给你一点提示，也希望你可以给我一些更好方法的提示，