2

サーバー上のいくつかのイベント ソースを照会する jquery カレンダー ウィジェットがあり、これらのソースはすべて同じ JSON 形式の応答を返します。

本当に厄介なのは、ユーザー Cookie の有効期限が切れると、これらのソースがすべてユーザーをログイン ページにリダイレクトし、HTML コンテンツを返すことです。

フィドラーでリクエストを確認したところ、2 つのリクエストが行われていることがわかります。1 つ目は、http ステータス 302 でイベントを更新する jquery カレンダー オブジェクトからのリクエストで、http ステータス 200 でログイン ページへのリクエストの直後です。

GET /xyz/Adempimenti/GetEvents?_=1289170335910&start=1288566000&end=1291590000 HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Accept: application/json, text/javascript, */*; q=0.01

HTTP/1.1 302 Found
Cache-Control: private
Content-Type: text/html; charset=utf-8
Location: /xyz/Login/LogOn?ReturnUrl=%2fxyz%2fAdempimenti%2fGetEvents%3f_%3d1289170335910%26start%3d1288566000%26end%3d1291590000&_=1289170335910&start=1288566000&end=1291590000

私のサイトは ajax 呼び出しに深く基づいており、カレンダーのこの 1 つは、私が直面している問題を説明するための単なる例です。すべての ajax 呼び出しでエラーを処理してリダイレクトすることを避けたいと思います。最適な方法は、セッション Cookie の有効期限が切れたときにユーザーを自動的に切断する方法を見つけることです。セッションの有効期限が切れたことを示すダイアログを自動的に作成する Web メール システムで、これが実装されているのを見たことがあります。

この方向について何か助けはありますか？

4

2 に答える 2

4

HTTP_X_REQUESTED_WITHjQuery が AJAX リクエストを実行すると、ヘッダーが送信されます。

サーバー側でそのヘッダーをチェックすることを検討しましたか? セッションがタイムアウトした場合、ログイン ページにリダイレクトする代わりに、「ログインしてください」というエラー メッセージを含む JSON 構造を返すことができます。

それが私の目には最もクリーンな方法です。

もう 1 つのアイデアは、「実際の」リクエストを行う前に追加の Ajax リクエストを作成することです。最初のリクエストが失敗するか、text/htmlコンテンツ タイプが返された場合は、ログインしていないことがわかります。あまり洗練されていませんが、クライアント側でセッション期間を数えようとするよりは簡単です (これは信頼できないに違いありません)。

于 2010-11-07T23:48:44.643 に答える
1

タイムアウト情報がサーバー側に保存されているセッションを扱っていると思います（クライアントは、セッションがいつ有効でなくなるかを必ずしも知りません）。その情報を取得し、リクエストとともにクライアントに送信します。a simplesetTimeout(notifySessionExpiration, sessTimeout * 1000)はそのトリックを行います。

周辺の質問に答えるには:

$ajax = isset($_SERVER['HTTP_X_REQUESTED_WITH']) && 
($_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest')

$ajaxXML リクエストを処理している場合、ブラウザーが準拠ヘッダーを送信すると仮定すると、true に設定されます (最近はそうする傾向があります)。

302 を送信するコードの部分 (セッションに基づいてユーザーの個人情報をフェッチするアプリケーション全体のコントローラー) を分離し、$ajaxtrue の場合に例外をまとめることをお勧めします。おそらく 401 または 403 を送り返し、Javascript コールバックが特定の方法でそのステータスに応答するようにします (たとえば、ログイン ページにリダイレクトするか、ポップアップ Ajax ログイン オーバーレイを提供します)。

これが単なるおもちゃのサイトであり、より堅牢なソリューションを作成するために手を汚しても構わないと思っている場合は、次の推奨事項を作成できます.

  • 意味論的に誤解を招く XHR 検出器を使用しないでください。私の意見では、異なるコンテンツを異なるリクエスタに配信することは、リクエスタに特定の適応 (ブラウザの癖など) を備えた同じようなコンテンツである場合、完全に合理的です。しかし、特定のリクエスターが根本的に異なる機能的役割を持っている場合 (たとえば、JSON/XML 応答を期待して XHR が送信される場合と、ブラウザーが HTML の通常の HTTP 要求を送信する場合)、その要求は、同じ資産。私の意見では、XHR に合わせたコンテンツはorの性質を持つべきですが.html、拡張子のないパス (たとえばGET /mypage.htmlor ) のHTML を生成するのがベスト プラクティスです。これは、XHRが決してすべきではないと言っているわけではありませんGET /mypageGET /mypage.jsonGET /mypage.xmlHTML 応答を取得します。ログイン フォームの HTML スニペットをロードしている場合や、ページ遷移に AJAX を使用しているだけの場合など、完全に適切な場合もあります。
  • セッションを維持するためのシステムを実装します。ブラウザーが閉じられるまで持続するのではなく、時間だけでセッションを期限切れにする必要がある場合は、期限切れになる前に単純な AJAX 要求でセッションを更新するクライアント側の呼び出しを入れます (ページが閉じている場合、リクエストは起動されず、割り当てられた時間が経過するとセッションが期限切れになります)。
于 2010-11-08T00:18:16.880 に答える