2011-01-05 214 views
0

以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); 

有没有人曾经处理这个问题之前?我也可以检查密码是否相同,但这是一个自定义的事情。

谢谢。

+0

是否每个请求都发送用户名和密码?如果是这样,我认为缓存没有意义。 – Raghuram 2011-01-06 07:46:50

+0

如果您想保存DAO呼叫,这是有道理的。 – 2011-01-06 17:17:15

回答

2

如果您配置了标准组件应用程序,该方案应该如下:

  1. Authentication对象被创建并与用户提供的用户名和密码填入用户请求到达。

  2. 用户详细信息被检索:如果可能的话,UserCache用于检索先前高速缓存的用户的信息(即getUserFromCache被称为或者通过的UserDetailsServiceAuthenticationProvider被执行以AuthenticationManager呼叫之前实现)。并且从缓存中的用户详细信息将带有良好的密码是100%。

  3. 后基本认证前的检查(凭证到期等)发生实际的认证。此时,来自缓存用户详细信息的密码将与提供的Authentication对象(当前包含错误密码)中存储的密码进行比较。此时认证尝试失败。

但是,如果实现自己AuthenticationProviderAuthenticationManager,您负责密码检查。

+0

最后我不得不自己做密码检查,因为我有一个自定义的AuthenticationProvider。谢谢。 – 2011-01-06 17:18:08

0

什么是最初从数据库中获取用户和缓存它的代码?它检查密码吗?听起来就像你有一个抽象问题 - Spring Security不应该知道用户来自哪里(数据库或缓存),并且应该使用相同的逻辑。

+0

是的,最初获取密码并缓存用户对象(以及密码)。但是,当下面的请求出现时,Spring会根据用户名检查用户是否被缓存,如果它在缓存中,则认为用户名认证成功。那就是问题所在。 – 2011-01-05 21:04:00