2011-01-05 19 views
0

私はここのように説明し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

+0

DAO呼び出しを保存する場合は意味があります。 –

答えて

2

あなたは標準のコンポーネントを使用してアプリケーションを設定した場合、次のように、シナリオは次のようになります。

  1. Authenticationオブジェクトはユーザーが入力するユーザー名とパスワードと作成されたユーザ要求到着時に。

  2. ユーザ詳細が検索される:それは可能だ場合、UserCacheが以前にキャッシュされたユーザーの詳細を取得するために使用される(即ちgetUserFromCacheのいずれかと呼ばれUserDetailsService又はAuthenticationProviderAuthenticationManagerへの呼び出しが行われる前の実装によって)。そして、キャッシュからのユーザーの詳細には良いパスワードが付いてくることが100%OKです。

  3. 基本的な事前認証チェック(資格情報の有効期限など)後、実際の認証が行われます。この時点で、キャッシュされたユーザーの詳細からのパスワードは、Authenticationオブジェクト(現在は間違ったパスワードを含む)に格納されているパスワードと比較されます。この時点で、認証は失敗します。あなたが独自のAuthenticationProviderまたはAuthenticationManagerを実装する場合

はしかし、あなたは、パスワードのチェックを担当しています。

+0

最終的に私は独自の認証プロバイダを持っていたので、自分でパスワードチェックをしなければなりませんでした。ありがとう。 –

0

元々DBからユーザーを取得してキャッシュするコードは何ですか?パスワードを確認しますか?あなたが抽象化の問題を抱えているように聞こえる - Spring Securityは、ユーザがどこから来ているのかを知るべきではなく(DBまたはキャッシュ)、どちらの場合でも同じロジックを使用する必要があります。

+0

はい、元々パスワードを取得し、ユーザーオブジェクト(パスワードと共に)をキャッシュします。しかし、次のリクエストが来ると、Springはユーザー名に基づいてユーザーがキャッシュされているかどうかをチェックし、キャッシュにある場合は認証が成功したものとみなします。それが問題だ。 –

関連する問題