2011-01-05 4 views
0

Использование Spring Security У меня есть DaoAuthenticationProvider описано, как здесь:Spring Security userCache недействительности

http://static.springsource.org/spring-security/site/docs/2.0.x/reference/dao-provider.html

У меня также есть кэширование (также, как это описано в этой статье).

Проблема заключается в том, что когда запрос приходит с хорошим именем пользователя (это уже в кеше), но с плохим паролем - он возвращает пользователя из кеша, как если бы он был хорошим именем пользователя/паролем. Поскольку он использует имя пользователя в качестве ключа, пароль вообще не задействован.

Точный код, который возвращает пользователю из кэша:

UserDetails user = this.userCache.getUserFromCache(username); 

ли кто-нибудь когда-либо дело с этой проблемой раньше? Я также могу проверить, является ли пароль одинаковым, но это будет обычай.

спасибо.

+0

Является ли имя пользователя и пароль отправлены по запросу? Если это так, я думаю, что кеширование не имеет смысла. – Raghuram

+0

Имеет смысл, если вы хотите сэкономить на вызовах DAO. –

ответ

2

Если вы настроили приложение с помощью стандартных компонентов, сценарий должен выглядеть следующим образом:

  1. В пользовательском прибытии обратиться с ходатайством об Authentication объекте создается и заполняется с именем пользователя и паролем, предоставленного пользователем.

  2. Данные пользователя извлекаются: если это возможно, UserCache используется для извлечения ранее кэшированные данные пользователя (т.е. getUserFromCache вызывается либо реализаций UserDetailsService или AuthenticationProviderперед тем выполняется вызов AuthenticationManager). И на 100% нормально, что данные пользователя из кеша будут иметь хороший пароль.

  3. После основных проверок предварительной проверки подлинности (истечения срока действия и т. Д.) Происходит фактическая аутентификация. На этом этапе пароль из кэшированных данных пользователя сравнивается с паролем, хранящимся в объекте Authentication (который в настоящее время содержит неправильный пароль). В этот момент попытка аутентификации не выполняется.

Однако, если вы реализуете свой собственныйAuthenticationProvider или AuthenticationManager, вы несете ответственность за проверку пароля.

+0

В конце концов, мне пришлось выполнять свою собственную проверку пароля, так как у меня был пользовательский AuthenticationProvider. Благодарю. –

0

Какой код изначально получает пользователь из БД и кэширует его? Проверяет ли пароль? Похоже, что у вас проблема с абстракцией - Spring Security не должна знать, откуда идет пользователь (DB или Cache), и должна использовать одну и ту же логику в любом случае.

+0

Да, это изначально получает пароль и кэширует пользовательский объект (вместе с паролем). Но когда приходит следующий запрос, Spring проверяет, кэшируется ли пользователь на основе имени пользователя, если он находится в кеше, он предполагает, что аутентификация прошла успешно. Это проблема. –

Смежные вопросы