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。