春季安全userCache无效
以Spring Security我喜欢这里描述的DaoAuthenticationProvider
:春季安全userCache无效
http://static.springsource.org/spring-security/site/docs/2.0.x/reference/dao-provider.html
我也有缓存(也喜欢在那篇文章里定律描述)。
的问题是,当一个请求具有良好的用户名进来(即已经在缓存),但错误的密码 - 它返回缓存用户,如果它是一个很好的用户名/密码。因为它使用用户名作为密钥,所以根本不涉及密码。
从缓存中返回用户的确切代码:
UserDetails user = this.userCache.getUserFromCache(username);
有没有人曾经处理这个问题之前?我也可以检查密码是否相同,但这是一个自定义的事情。
谢谢。
如果您配置了标准组件应用程序,该方案应该如下:
在
Authentication
对象被创建并与用户提供的用户名和密码填入用户请求到达。用户详细信息被检索:如果可能的话,
UserCache
用于检索先前高速缓存的用户的信息(即getUserFromCache
被称为或者通过的UserDetailsService
或AuthenticationProvider
被执行以AuthenticationManager
呼叫之前实现)。并且从缓存中的用户详细信息将带有良好的密码是100%。后基本认证前的检查(凭证到期等)发生实际的认证。此时,来自缓存用户详细信息的密码将与提供的
Authentication
对象(当前包含错误密码)中存储的密码进行比较。此时认证尝试失败。
但是,如果实现自己AuthenticationProvider
或AuthenticationManager
,您负责密码检查。
最后我不得不自己做密码检查,因为我有一个自定义的AuthenticationProvider。谢谢。 – 2011-01-06 17:18:08
什么是最初从数据库中获取用户和缓存它的代码?它检查密码吗?听起来就像你有一个抽象问题 - Spring Security不应该知道用户来自哪里(数据库或缓存),并且应该使用相同的逻辑。
是的,最初获取密码并缓存用户对象(以及密码)。但是,当下面的请求出现时,Spring会根据用户名检查用户是否被缓存,如果它在缓存中,则认为用户名认证成功。那就是问题所在。 – 2011-01-05 21:04:00
是否每个请求都发送用户名和密码?如果是这样,我认为缓存没有意义。 – Raghuram 2011-01-06 07:46:50
如果您想保存DAO呼叫,这是有道理的。 – 2011-01-06 17:17:15