本文主要介绍已经使用spring-security的项目集成spring-session时的一些问题及解决方案。
maven依赖相关组件及版本号：
Spring: 3.1.1.RELEASE
Spring-Security：3.1.0.RELEASE
spring-session-data-redis：1.3.0.RELEASE
cglib: 2.2.2
项目背景及目标：实现分布式session。
也有一些其他方案可以解决分布式session的问题，比如nginx的ip_hash策略，根据客户端的IP始终路由到同一台服务器，方便快捷。但必须是Nginx负载，由于生产环境使用F5负载，因此需要用上spring-session，把session存到redis中。
实现步骤：
1.添加POM信息及相关配置文件
pom.xml
其中，cglib是切面编程要用到，视具体项目情况，编译时会有日志提示添加。
spring-session-data-redis下的exclusions可视自己项目的情况添加。
spring-session.xml
这地方我们的项目使用jedis连接redis，spring官方文档用lectture。
redis.properties
applicationContext.xml
在springContext配置文件中，引入相关配置。
spring-security.xml
在spring-security配置中，将sessionRegistry修改为SpringSessionBackedSessionRegistry。
web.xml
在web.xml中添加spring-session的filter。
注意：在spring-security集成spring-session时，二者都用到filter。应该将spring-session的filter写在最前面，最先执行。因为spring-security在处理过程中要用到session，应该让spring-session的filter先对HttpSession进行包装。
如果项目比较简单，以上配置完成后，应该就可以正常启用spring-session了。
2.自定义SecurityContextRepository解决实际项目问题
在本次配置的系统中，系统本身不访问数据库，全部通过调用hessian服务获取数据。
而spring-security在进行身份认证时，会生成一个token（即Authentication），这个token实现了一个带有getAuthorities()方法的接口。导致生成的token在存到session后，将session存到redis时，会报错HessianProxyFactoryBean无法序列化。这里，把hessian的具体接口实现Serilizable也无济于事。
此处，我研究了一下token的authorities属性，发现已经获取到了权限，并且hessian的service相关信息应该已经没什么实际用处了。token也提供了相关的构造方式，这里选择重新生成一个不带hessian代理信息的token。
这样需要改写spring-security自带的HttpSessionSecurityContextRepository，并将其替代。
具体代码及配置如下图：
RedisSessionSecurityContextRepository.java
注意：这里往session存context的key "SPRING_SECURITY_CONTEXT"不能变动，否则会影响spring security对session内容的判断。
spring-security.xml
在spring-security的配置文件中，添加我们改写的bean，并配置到http切入点中去。
至此，对整个系统的改造完毕。启动Nginx负载两个端口，发现分布式的session已经实现。
总结：
1.程序的执行顺序很重要。在web.xml中，写在前面的Filter先执行。
添加配置时，习惯将新加的配置添加在最下方，导致最开始时没注意这个顺序问题。spring-session的flter总是最后执行，发现运行时，session存到redis中，但每次会话开始时读的是httpSession（此时httpSession尚未被包装，因此读不到redis中存的session内容)，还花了一番功夫把读httpSesion改成了读redisSession，倒也让程序正常跑起来实现了分布式session。
后来想了一下，spring-session对代码是无侵入的，对httpSession做了包装，才想到是执行顺序的问题。
Filter是servlet的机制，Interceptor是spring-mvc的机制。web.xml中配置的所有filter构成一个FilterChain，依次执行，然后到spring-mvc的dispatcherServlet，在这个servlet中被spring-mvc的Inteceptor依次拦截，最终到spring-mvc的controller中。即filter --> dispatcherServlet --> interceptor --> controller。
