これはすでに質問されていることは知っていますが、機能させることができません。これが私が達成したいことです：
Spring Security 3.2 を使用して REST のようなサービスを保護しています。サーバー側のセッションはありません。基本認証は使用していません。これは、ユーザーのパスワードをクライアント側の Cookie に保存する必要があることを意味するためです。そうしないと、ユーザーはページを更新/変更するたびにログインする必要があります。トークンを保存することは、悪が少ないと思います。
- Web クライアント (ブラウザー、モバイル アプリ) が REST のような URL を呼び出して、ユーザー名とパスワードで "/login" にログインします。
- サーバーはユーザーを認証し、トークンをクライアントに送り返します
- クライアントはトークンを保存し、各 API 呼び出しでそれを http 要求ヘッダーに追加します。
- サーバーはトークンの有効性をチェックし、それに応じて応答を送信します
トークン生成の部分はまだ見ていません。私はそれが逆であることを知っていますが、トークン検証部分を最初に実装したかったのです。
カスタムファイラー（AbstractAuthenticationProcessingFilterの実装）を使用してこれを達成しようとしていますが、それについて間違った考えを持っているようです。
次のように定義します。
public TokenAuthenticationFilter() {
super("/");
}
この正確な URL に対してのみフィルターをトリガーします。ワイルドカードを受け入れない AbstractAuthenticationProcessingFilter#requiresAuthentication を呼び出すいくつかのサンプル実装に固執しています。もちろん、私はその振る舞いを変えることができますが、これはどういうわけか私が間違った道を進んでいると思わせます.
また、カスタム AuthenticationProvider の実装も開始しました。多分それは正しいことですか？誰かが私に正しい方向へのプッシュを与えることができますか?