spring security 3

第二种方法中遇见的问题

当然，首次使用Spring serutiry，在整合的过程中，我还是遇见了不少问题，当然有些问题比如找不到类呀，包呀，和框架的整合呀等问题不作为谈论的重点。主要还是探讨Spring Security的配置和注意事项的问题。

我在其中碰到的对我印象最深的问题是，当完全配置好之后，重启Web服务器，却发现Spring Security不能拦截任何的URL了，这使我感到惊诧，因为在去年时，我已经将该框架搭建完成，在当时正是使用的该种方法，并且在试验是否能够拦截jsp文件时进行了确认是没有问题的。

接下来我又整理了一下applicationContext-security.xml的文件才发现， 除了不需要进行检测的图片及登录页面之外，没有对任何的资源和权限之间的对应关系进行配置，参见下面的代码：

< http  auto-config ="true"  access-denied-page ="/accessDenied.jsp" >
<!--  不要过滤图片等静态资源，其中**代表可以跨越目录，*不可以跨越目录。  -->
< intercept-url  pattern ="/**/*.jpg"  filters ="none"   />
< intercept-url  pattern ="/**/*.png"  filters ="none"   />
< intercept-url  pattern  filters ="none"   />
< intercept-url  pattern ="/**/*.css"  filters ="none"   />
< intercept-url  pattern ="/**/*.js"  filters ="none"   />
<!--  登录页面和忘记密码页面不过滤  -->
< intercept-url  pattern ="/login.jsp"  filters ="none"   />
< intercept-url  pattern ="/jsp/forgotpassword.jsp"  filters ="none"   />  

<!--  下面是对Struts2的Action请求时的配置。注意在前面加/，否则不会被SS3进行拦截验证。
表示具有访问/unitsManager资源的用户必须具有ROLE_PLATFORMADMIN的权限。
当用户登录时，SS3将用户的所有权限从数据库中提取出来，形成列表。 当用户访问该资源时，
SS3将登录用户的权限列表提出来跟下面配置的权限进行比对，若有，则允许访问，若没有，
则给出AccessDeniedException。 
<intercept-url pattern="/unitsManager" access="ROLE_PLATFORMADMIN" />
<intercept-url pattern="/usersManager" access="ROLE_PLATFORMADMIN" />
<intercept-url pattern="/horizontalQuery" access="ROLE_PLATFORMADMIN" /> 
<intercept-url pattern="/verticalQuery" access="ROLE_PLATFORMADMIN" />  -->

< form-login  login-page ="/login.jsp"  
authentication-failure-url ="/login.jsp?error=true"
default-target-url ="/index.jsp"   />

<!--  "记住我"功能，采用持久化策略（将用户的登录信息存放在数据库表中）  -->
< remember-me  data-source-ref ="dataSource"   />

<!--  检测失效的sessionId,超时时定位到另外一个URL  -->
< session-management  invalid-session-url ="/sessionTimeout.jsp"   />

</ http >

这样一来，spring security3就会认为根本不需要对任何的URL或Action进行检测(注意上面代码中被注释掉的4条配置)。 哈哈，当时这个问题深深动摇了我对Spring security的信心，花费了这么多天的精力，却是这样的结果，当时就在考虑是否有更好的替代品。有点崩溃啊。 还好，深深地求知欲和征服欲让我坚持下来了。
哈哈，这算不算Spring Security的一个Bug呢？没有任何的权限与资源的配置，就认为登录后的用户具有访问任何资源的权限，说起来有点可怕哈。

当然，当我将上述代码中被注释的4条配置放开后，Spring security奇迹般的恢复了活力。

接下来实现了jsp型URL的拦截之后，我又遇见了不能拦截action的情况，不过经过多次的配置和重启服务试验，终于发现，在配置Action与权限时，一定要在Action的路径前面加“/”斜杠，否则，Spring Security就会对该请求的URL熟视无睹，无视它的存在，即使你在Action的前后加上*号进行匹配也不会起任何作用，哈哈，不禁慨叹Spring Security的牛脾气。

第二种方法BTW

顺便提一下子，Spring Security3需要配置的过滤器是双重的，首先在web.xml中配置一个过滤器代理，参见上述web.xml中的springSecurityFilterChain配置。
我们通常设置过滤的url模式为/*，就是说任何的url访问都要进行过滤，工作量有点大哈。当然我们可以为之设置不同的过滤url模式，比如.action、.do、.jsp等。这样的话，遇到.action或.jsp或.do结尾的url访问，Spring Security就会突然站出来打截，若是其他的访问，Spring Security就会挥一挥手，潇洒地让你路过。
所以说，这个过滤器主要对大的方面进行拦截，一些细小的活儿，还是要交给第二重过滤器。 就是说，这第一重过滤器是个总代理，他威武地管理着一个过滤器链。

那么这第二重过滤器的配置，就是那些所谓的过滤器链，分别包括“记住我”、“登录”、“注销”、“url访问”等的过滤器，这个过滤器依顺序排开，形成一个过滤链条。具体拦截我们明细Url的是一个叫做FilterInterCeptor的伙计，我认为这个家伙是在整个过滤器链条中是最重要的一个，因为我们登录系统之后，要访问的任何资源都必须经得他的同意。 那么这第二重链条就设置在applicationContext-security.xml文件中的<http>元素下面。
什么，你看不到？ 忘记告诉你了，从spring security2开始，就使用了命名空间，若你在<http>中设置了auto="true"，Spring Security就会在服务启动时自动加载
所有的过滤器链，省事了吧！

 

第三种方法

当然，spring security3毕竟是西方国家的东西，以英文为主，使用习惯和文化的差异共存，况且为了适应大多数Web应用的权限管理，作者将Spring Security3打造的精简而灵活。精简指Spring Security3对用户和权限的表设计的非常简单，并且没有采用数据库来管理资源（URL）。这样的话，对于我们国人用户来说，是个很大的遗憾，这个遗憾甚至能够影响到我们对安全框架的选型。你想啊，在国内大多数项目中，均设置了比较复杂的权限控制，一般就会涉及到用户、角色、权限、资源4张表，若要加上4张表之间的对应关系表3张，得有7张表才行。

得7张表才行，但是Spring Security3才给我们提供了2张最简洁的表，这足以不能完成国人用户的项目应用。那么在对Spring Security3一无所知的情况下，
我们很容易就会放弃对该安全框架的选型。

还好，Spring Security3提供了灵活的扩展方法。具体应该扩展哪些类呢？ 或者到底Spring Security3工作的流程如何，你不妨参看下面一篇文章，就会获得
一些启示，网址为：http://www.blogjava.net/youxia/archive/2008/12/07/244883.html ， 哈哈，谢谢分享。

还有一个地址很有价值， http://wenku.baidu.com/view/4ec7e324ccbff121dd368364.html ，我就参考着上面的介绍扩展了4个类。

不过我得提一下，原文的作者为了考验你的耐性和自信心，故意在代码里面卖了几点小小的关子，因此若是完全按照作者的原文代码装配起来的权限系统，是不会那么顺利地工作的，天下似乎真是没有不花费力气的午餐！在装配完成后，我也是经过九九八十一难的折磨，在用户、角色、权限、资源的
“天下黄河九曲十八弯”里面盘旋迂回，终于到达了成功的彼岸。至此才对Spring Security有了更深层次的理解，更加佩服作者的良苦用心。 哈哈。

并扩展了User类以增加其相关的各类其他信息(如Email，职务，所在单位id等)。