私のWebアプリケーションは、サーバー側に多くのAjax呼び出しで構成されています。RESTful APIs顧客が自分のサイトにログインするたびに、ログインページはサーバーからJWT（JSON Webトークン）トークンを取得し、クライアント側にcookieとして保存します。 （ブラウザに自動的に送信させる唯一の方法であり、HTML5 Web Storageよりも安全だと言われているので、Cookieとして保存することを選択します）。トークンにはトークンの有効期限を記述するフィールドがあります。 Ajaxコールごとに、トークンが認証のために送信されます。Ajaxコールのログイン有効期限を正常に処理する方法は？
クライアントが自分のページに長時間滞在している場合、トークンは期限切れになる可能性があります。クライアントは次のHTTP要求（REST呼び出しだけでなく）を行ったときにサーバーがそれを検出します。 servlet filterを使用してall HTTPリクエストを傍受し、有効期限のトークンを確認します。トークンが期限切れの場合、リダイレクトからログインページの応答が送信されます。
しかし、上記のアプローチについての問題があります：「優雅にクライアント側でリダイレクト・ツー・ログイン・ページ応答を処理する方法は？」 non-Ajaxについては
HTTPリクエストを発信し、私はリダイレクト・ツー・ログイン・ページの応答を処理し、自動的にページをジャンプさせるために、ブラウザに依存することができます。
Ajaxについてはは、HTTPリクエストを発し、私がリダイレクト・ツー・ログイン・ページの応答を検出し、
imperativelyページジャンプを作るためにeachAJAX呼び出しのcompletion handlerに余分なロジックを追加する必要がありそうです。
まったく間違っていますか？
いくつかの参照文献：
JWT (JSON Web Token) automatic prolongation of expiration
Which authentication strategy should I use for my API?
Implicit & Explicit authentication
ADD 1：
ブラウザが302 redireを処理するようです透明にしてください。 おそらく、私はログインページに302リダイレクトを返すことができます。これは、ajax呼び出しやプレーンページ訪問のためのものです。私は後でやってみます。
hereより：
応答はHTTPリダイレクト（状態コード301、302、303又は 307）である場合（それは セキュリティまたは無限ループ注意事項に違反していない限り）、それは透明に従わなければなりません。その他のエラー（ 401を含む）は、オブジェクトにそのエラーページを応答として使用させなければならない。
Catching 302 FOUND in JavaScript
How to manage a redirect request after a jQuery Ajax call
私は今までこれについて知らなかった。 HTTPの規約に従うようです。どうもありがとう！ – smwikipedia
ところで、これはWeb APIが302レスポンスを返してはならないと言っているわけではありません。リソースが実際に移動した場合は、301または302を返すのは問題ありません。しかし、Web API IMOの認証メカニズムを実装するためには使用しないでください。 – MvdD
はい。 *フォームは関数に従います*。 – smwikipedia