spring-security整合spring-session，实现分布式session

本文主要介绍已经使用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

---

部分参考文档：

spring-session 1.3.0.RELEASE 官方文档：

https://docs.spring.io/spring-session/docs/1.3.0.RELEASE/reference/html5/#samples

spring-session 源码及原理解析：

https://www.cnblogs.com/lxyit/p/9672097.html

---

项目背景及目标：实现分布式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。