これは重複としてマークされる可能性が高いことを知っていますが、探しているものを正確に見つけることができませんでした

これは一般的な問題であり、明確に定義されたベストプラクティスソリューションがあるはずです。

バックグラウンド

1. 単一ページのSaaSアプリ、ドラッグアンドドロップがたくさんあり、ユーザーは一定期間サーバー通信がなくてもアプリを操作できます

2. サーバーセッションは、非永続的なセッションCookieを使用して、ユーザーオブジェクトのみを保持します

3. X時間後にサーバーでセッションが期限切れになる

4. ログイン時にのみ読み込まれるもの

問題

1. ユーザーはアプリで作業し、完了してもログアウトせず、ブラウザーを開いたままにします
2. ユーザーがX時間を超えて戻ってきた（セッションがサーバーで無効になっている）
3. ユーザーはサーバー接続を必要とせずにアプリと対話します（ドラッグアンドドロップ、テキスト編集など）
4. 次のサーバーとの対話時のみ（自動保存がないと仮定）、ユーザーはログインページにスローされ、一部の作業が失われます

可能な解決策

私が考えているいくつかの解決策があります。他に解決策があるかどうか、そして根本的に何か問題があるかどうかを聞きたいです。

1.ユーザーをログアウトしないでください

• どうやって？長いセッションを維持する、永続的なcookieを維持する、またはjavaScriptの「キープアライブ」ping
• 長所：ユーザーは何も心配する必要がなく、問題を修正します
• 短所：PCIに準拠せず、安全ではなく、開発の変更が必要です。たとえば、ユーザーのログイン時にのみセッションに読み込まれるものは、pubサブモデル（イベントの変更をリッスンする）に移動するか、キャッシュタイムアウトを持つ必要があります。

2.ローカルストレージ

• どうやって？ログアウトした場合、新しいローカルストレージを使用して状態を一時的に保存し、ログインページにリダイレクトし、ログイン後も保持する
• 長所：セッションタイムアウトの処理だけでなく、「オフライン作業」サポートのベース
• 短所：実装が難しく、データツリーの状態マージを行う必要がある、すべてのブラウザがサポートするわけではない

3.自動保存

モデルを変更するすべてのユーザーアクションは、すぐに（またはクライアント側のキューを介して）永続化する必要があります。たとえば、ユーザーがチェックボックスをオンにしたり、テキストフィールドを変更したり、何かをドラッグアンドドロップしたりすると、変更が永続化されます。

• どうやって？MV **フレームワーク（Backbone.js / Knockout.js / Ember.js / Angular.jsなど）を使用してモデルをバインドし、変更を維持します。
• 長所：クリーンなソリューションのようです。ユーザーがアクティブである限りセッションはアクティブであり、永続化せずにクライアント側の作業は行われません。
• 短所：セッションタイムアウトが失われた後、ユーザーが最後に行ったアクション。

4.セッションの有効期限が切れた後、ユーザーをログアウトします

これにはいくつかのアプローチがあります

1. サーバーに「セッションの期限が切れています」と尋ねます。これは、サーバーへの単なる質問がセッションを延長する（タイムアウトを再開する）ため、ちょっとしたキャッチ22 /シュレディンガーの猫です。

   • どうやって？そのような質問をサポートするサーバーを持っているか（私は知りませんが、Javaランドから来ます）、またはセッションIDのテーブルと最終アクセス時間を手動で保持し、セッションを渡すことによってサーバーに問い合わせることができますCookieの代わりにパラメーターとしてIDを使用します。これが可能かどうかはわかりませんが、危険で、安全でなく、設計が間違っているようです。
   • 長所：サーバーにそのようなネイティブサポートがあった場合、クリーンで正当な質問のように聞こえます（ユーザーXがまだセッションを持っているかどうかを尋ねます）
   • 短所：サーバーがそれをサポートしていない場合（そして、サーバーやフレームワークにこの機能があるかどうかはわかりません）、回避策には潜在的に大きなセキュリティリスクがあります。

2. 私が聞いた1つの回避策は、サーバー側での短いセッションと、最大数のpingを持つキープアライブクライアント側のpingです。

   • どうやって？サーバー上の短いセッション、クライアントはすべてのsessionTimeOut / 2にpingを実行し、最大再試行回数はYです。
   • 長所：問題の修正の種類、迅速で汚い
   • 短所：サーバーに任せるのではなく、自分でセッションの更新を処理するハックのように感じる

3. クライアント側タイマー

   • どうやって？クライアント側にタイマーを設定し、すべてのリクエストで再起動してサーバーのタイマーと同期させ、最大サーバーセッションタイムアウトからパディングを差し引いた値に等しくします。ユーザーがサーバーにリクエストを送信していない後、UIに「セッションは間もなくタイムアウトします。続けますか？」（あなたがオンラインバンキングに持っているように）

   • 長所：問題を修正します

   • 短所：同期が機能することを確認する必要性以外は考えられません

質問

上記の分析で何か見落としているかもしれませんし、ばかげた間違いがあるかもしれません。それらを修正してください。このために他にどのような解決策がありますか？

最も一般的な単純な解決策は、通常のタイムアウトウィンドウの特定の部分が経過した後にメッセージを表示するタイマーをクライアントエンドに設定し、アクションが実行されない場合にセッションが期限切れになる直前に強制的にログアウトすることだと思います。

ローカルストレージと自動保存は、トランザクションに関するいくつかの問題と、保存されたものの実際の意味をもたらします。私はかなりの数のプロジェクトに携わってきましたが、ユーザーベースがその背後にあるメカニズムを理解していない場合、これは価値があるよりも厄介なことが判明しました。

ログアウトは規制で許可されている場所では絶対に実行できませんが、誰かが予期せずログアウトした場合に何が起こったのかを正しく処理できず、追跡することが非常に多い場合、すべての州のビジネスが維持するのに少し集中的になるミスにつながります「アクティブ」ユーザー。

私が聞いた1つの回避策は、サーバー側での短いセッションと、最大数のクライアント側のpingを維持するpingです。

どうやって？サーバーでの短いセッション、クライアントはすべてのsessionTime / 2にpingを送信し、最大の再試行回数はYです。長所：問題の種類の修正、迅速で汚い短所：ハックのように感じ、サーバーに任せる代わりにセッションの更新を処理する>

これは私の意見では最良の解決策です。なぜあなたはそれを「汚いハック」と考えますか？

それはまさに何をしなければならないかを作ります。ユーザーがプログラムを操作している間、セッションは開いたままになります。

ユーザーがプログラムでの作業を停止した後、セッションは閉じられます。

実装するのに十分単純です。

質問が正しく理解できれば、まさに何が必要か。

これを扱うアプリケーションを実際に作成しています。

まず、Django、Guradian、Tastypieを使用してRESTfulサービスを作成しました。APIKEYのみを使用して認証し、オブジェクトへの承認はGuardianによって処理されます。

djangoアプリには、base.htmlをロードするテンプレートビューurlconfが1つしかありません...

クライアント側では、Angularを使用してアプリケーションを作成しました。

認証に関する限り、401応答をリッスンするhttp-auth-interceptorがあります。

401が受信されると、発信要求がバッファリングされ、「ログインが必要」というイベントが発生します。これは数回発生する可能性があります。

「login-required」イベントが聞こえたときに表示されるログインフォームを含むモーダルポップアップがあり、APIKEYも含まれるユーザーリソース（JSONバンドル）を返すログインを実行します。

以前に401応答になったすべてのバッファリングされた要求は、Authorization httpヘッダーに含まれるAPIKEYで再生されます。

別の角度のあるサービス/ファクトリーを使用してlocalstorage jsonデータを管理し、そこにユーザー名とapikeyを保存します。

解決しなければならない唯一のパズルは、その情報を保護する方法と、その情報にタイムアウトを適用する方法です。

おそらく、最後の有効なhttpリクエストからのタイムスタンプチェックを使用します。

私の場合、4.1に似たものを使用しています。ユーザーがログインした後、非常に軽量な角度駆動のAJAX json要求がサーバーに対して一定の間隔でREST APIに発生します。セキュリティ要件のため、プロプライエタリなUIは、サーバーがユーザーのセッションを維持し、サーバー側で保護された情報、テンプレート、データなどを保存することを期待しています。これは、セキュリティの観点からはまだ私の推奨方法です。機密データ（ハッシュされたパスワードなどだけでなく）を処理する場合、IMOをクライアント側でローカルストレージなどに格納すると、サーバー側よりもリスクが高くなります（誰かが私と議論することは間違いありません）。サードパーティは、システムとの通信時に同じAPIを使用しますが、すべてのリクエストで認証資格情報を送信する必要があります。

サーバー上のセッションには最大アイドルライフタイムが適用されており、セッションストレージエンジンはmemcachedです（メモリセッションに期限切れのマークが付けられる時点で最大ライフタイムも適用されます）。存続期間は、アプリケーションで抽象化するどのセッション存続期間よりも長くする必要があるだけです（そして、それほど多くなくてもかまいません）。EGサーバーに関する限り、セッションが48時間アイドルになるまでセッションは期限切れになりませんが、実際の存続期間はコードによって制御されます。これは、その存続期間が長すぎる場合、リソースの問題につながる可能性があり、セッションの管理が不十分です。

私の場合、組織内での役割に基づいて、ユーザーごとに異なるセッションアイドルタイムアウトを設定できます。サーバーはセッションの存続期間に最大制限を設定しますが、ユーザー定義の制限がそれらよりも小さい限り、問題なく機能します。サーバーがセッションを期限切れにすると、セッションの期限切れプロセスがアプリケーションによってすでに正常に処理されているため、これは重大な問題です。これは、私が構築した種類のビジネスアプリケーションの要件です。

ユーザーセッションがアイドル状態になり、アプリケーションで指定されたしきい値内になると、APIはUIにカウントダウンダイアログを表示するように指示します（銀行が行うように）、それが有効期限から一定の時間内にあると、正常に終了しますユーザーをログアウトします。この機能は、サーバーが制御しているため、ブラウザーウィンドウ全体で持続し、任意のウィンドウでのアイドルイベントにより、グレースフルタイマーと自動ログアウトプロセスが開始されます（同期を維持します）。

万が一セッションが異常な方法で期限切れになった場合（セッションはmemcachedにダンプされます）、サーバーに影響を与える次のリクエストはユーザーに通知し、それらをスクエアなものに戻します（まれに起こりますが、できます）。