現在、サーバー側で Dropwizard を使用し、クライアント側で RequireJS、バックボーンを使用して、REST アプリケーションに取り組んでいます。
当社の認証モデルは Cookie ベースです。要求ごとに、Web フィルターが適切な Cookie とその値であるトークンをチェックします。トークンがまだ有効な場合は、フィルター チェーンでリクエストを転送し、そうでない場合は 401 で応答します。
クライアント側では、次のようになります。
do an ajax request:
success:
render the rest of the content
error: // got 401
stop whatever you were doing and redirect to the login page
このアプローチの唯一の欠点は、クライアントがログイン ページにリダイレクトされる前に実際のページをダウンロードする必要があることです (もちろん 401 の場合)。
たとえば、a.html と b.html の 2 つのページがあります。クライアントがページa.htmlを閲覧していて、しばらくしてそのトークンの有効期限が切れた場合、まずバックグラウンドで ajax リクエストを実行するb.htmlをダウンロードする必要があります (上記を参照)。その後、ログイン ページにリダイレクトできます。 :
a.html (200) -> token expired -> b.html (200) -> login.html (200)
これまで、作成したすべての REST アプリケーションでこのようなスタイルのエラー処理を使用していました。私が見たいのは、たとえば次のとおりです。
a.html (200) -> token expired -> login.html (200)
ただし、これには、たとえば、サーバー側のフィルターでログイン ページの URL をハードコーディングし、通常はサーバー側のコードにロジックを結び付ける必要があります。
クライアント側でサーバー認証エラーを処理するためのより良い方法があると確信しており、それらについて知りたいです。