Node.jsでのクライアントセッションの使い方の詳細な説明 programming_node.js

静的 Web サイトは簡単に拡張できます。すべてをキャッシュするだけでよく、さまざまなサーバーからのステートフル コンテンツを組み合わせてユーザーに提供することについて考える必要はありません。

残念ながら、ほとんどの Web アプリケーションは、パーソナライズされたエクスペリエンスを提供するためにステートフル コンテンツを使用しています。アプリケーションがログインできる場合は、ユーザーのセッションを記憶する必要があります。古典的な処理方法では、クライアントがランダムな一意のセッション ID を含む Cookie を設定し、識別されたセッション データがサーバーに保存されます。

ステートフル サービスの拡張

サービスを拡張する場合、必ず 3 つのオプションがあります:

1. 異なるサーバー間でセッション データを同期する
2. 異なるサーバーが単一ポイントセンターに接続 (セッションを取得)
3. ユーザーが同じサーバーにアクセスしていることを確認します

しかし、それらにはすべて欠陥があります:

• データを同期するとパフォーマンスのオーバーヘッドが増加します
• 単一点中心によりシステムの拡張性が低下します
• ユーザーが最後にアクセスしたサーバーにメンテナンスが必要な場合の対処方法

しかし、別の角度から考えると、セッション データをクライアントに保存するという 4 番目のオプションが見つかります。

クライアントセッション

クライアント上でセッションを保存すると、いくつかの利点があります:

• どのサーバーであっても、セッションデータは有効です
• サーバーのステータスを維持する必要はありません
• サーバー同期は必要ありません
• 新しいサーバーを自由に追加

しかし、クライアント側のセッションには重大な問題があります。ユーザーがセッション データを改ざんしないことを保証することはできません。

たとえば、ユーザーの ID を Cookie に保存します。ユーザーはこれを簡単に変更して、他の人のアカウントにアクセスできるようになります。

これはクライアント側セッションの可能性を否定しているように見えますが、この問題をきちんと解決する方法があります。それは、セッション データ (Cookie に保存されたまま) を暗号化してパッケージ化することです。この方法では、ユーザーがセッション データを変更することを心配する必要はなく、サーバーがデータを検証します。

実際のアプリケーションでは、暗号化されたサーバーキーが Cookie に保存されます。サーバーキーの検証後にのみ、セッションデータの読み取りと変更の権限が与えられます。これはクライアントのセッションです。

ノードクライアントセッション

Node.JS には、クライアント側セッションを実装できるライブラリ (node-client-session) があり、Connect の組み込みセッションおよび cookieParser ミドルウェア (Node ミドルウェア フレームワーク) を置き換えることができます。

Express フレームワーク アプリケーションでの使用:

const clientSessions = require("client-sessions"); 

app.use(clientSessions({ secret: '0GBlJZ9EKBt2Zbi2flRPvztczCewBxXK' // 设置一个随机长字符串! })

次に、req.session オブジェクトにプロパティを追加します。

app.get('/login', function (req, res){ req.session.username = 'JohnDoe'; });

属性の読み取り:

app.get('/', function (req, res){ res.send('Welcome ' + req.session.username); });

リセット メソッドを使用してセッションを終了します:

app.get('/logout', function (req, res) { req.session.reset(); });

ペルソナ セッションをすぐにログアウトします

(注: ペルソナは Mozzilla によって開始されたオンライン ID システムです)

サーバー側のセッションとは異なり、クライアント側のセッションの問題は、サーバーがセッションを削除できないことです。

サーバーサイドアーキテクチャでは、セッションデータを削除できます。クライアント Cookie によって識別されるセッションは存在しない可能性があります。ただし、クライアント側のアーキテクチャでは、セッション データはサーバー側に存在しないため、すべてのクライアントでセッション データが削除されるという保証はありません。つまり、ユーザーのクライアント状態 (ログイン) とサーバー状態 (ログアウト) を同期することができません。

この欠陥を補うために、クライアント セッションに有効期限が追加されます。セッション データ (暗号化およびパッケージ化) を展開する前に、有効期限を確認してください。有効期限が切れた場合は、セッションデータを破棄し、ユーザーの状態を変更（ログアウトなど）してください。

有効期限メカニズムは、多くのアプリケーション (特に短い有効期限要件) で適切に機能します。たとえば、ペルソナ では、パスワードが脅迫されたり破損したりしたことをユーザーが発見した場合、ユーザーがセッション データから直ちにログアウトする方法を提供する必要があります。

これは、サービス バックエンドに少しの状態情報を保持することを意味します。インスタント ログアウトを処理する方法は、ユーザー データ テーブルとセッション データにトークンを追加することです。

API が呼び出されるたびに、セッション データ内のトークンがデータベース内のトークンと比較されます。そうでない場合は、エラー メッセージを返し、ユーザーを終了します。

これにより、トークンをクエリするための冗長なデータベース操作が追加されます。幸いなことに、ほとんどの API 呼び出しではユーザー データ テーブルを読み取る必要があるため、トークンを一緒に持ち込むだけで済みます。