Playのクライアント側セッションの使用例

Question

「クライアント側セッション」という言葉は、セッション中にすべてのデータがクライアントのクッキーに格納されているように見えます。そして、 "サーバー側のセッション"を使用することが知られているPHPは、私はすべてのデータをクッキーに格納することが可能だと思います。おそらく違いは、クッキーが秘密鍵で歌われるかどうかですが、わかりません。 「サーバー側セッション」と呼ばれる通常のセッションでは、セッションIDを持つCookieを設定してから、サーバーはセッションIDを処理し、関連する指定された値を見つけることができます。このセッションでは、クライアントにはセッションIDだけがあります。これは長い番号です。そして指定されたデータはサーバー側に格納されるので、私はそれが "サーバー側セッション"と呼ばれると仮定します。

私はこのアプローチも可能であることを知っています。つまり、クライアントにはセッションIDがあり、サーバーには通常キャッシュに指定されたデータがあります。 Playは秘密鍵で署名されたクライアントのクッキーにすべてのデータをプッシュすることを可能にしています。私は、「クライアント側のセッション」をどのようなタイプの実装に使用するべきですか？ 私は想像もしませんし、Playのセッションについての公式文書には深く言及していません。

どのようなユースケースですか？クライアントサイドのセッションはいつ実装しますか？ コメントや回答を高く評価してください。

Answer 1

サーバーサイドセッションの問題は、すべてのサーバーでレプリケートする必要があることです。

通常、Webサイトは複数のインスタンスに展開され、ロードバランサが前面に配置されているため、リクエストをアプリケーションインスタンスにランダムにルーティングします。セッションを動作させるには、データベースのような中央のデータストアにセッションを格納するか、セッションを複製することによって、すべてのサーバがアクセスできる必要があります。これにより、データベースのボトルネックを導入するか、複雑なレプリケーション・スキームを設定する必要があるため、スケーリングがやや難しくなります。

クライアント側のセッションには、すべての必要なデータが要求自体に含まれているという利点があります。そのため、サーバーはステートレスのままでお互いに通信する必要はありません。欠点は、セッションに大量のデータが含まれている場合にリクエストのサイズが増加し、リクエストごとにリクエストが再送信されることです。

セッションの最も一般的な使用例は、通常、ユーザーがログインしていることを示すためのユーザーIDなどを格納するだけですが、通常はセッショントークンよりもサイズが大きくなりません。したがって、この場合、セッションを取得するためのデータベースへのラウンドトリップを節約するなど、クライアント側セッションの方がはるかに効率的です。

クライアントサイドセッションのもう1つの欠点はセキュリティです。サーバーサイドセッションは概念的には気にするのがはるかに難しいので、Playはそれを署名することで問題を緩和します。人々が読むことができないと思われる機密データをセッションに保存しないようにしてください。

あなたのセッションが非常に小さい場合、基本的に、クライアント側のセッションが進む方法かもしれません。それらが大きい場合、またはセンシブデータが含まれている場合は、サーバー側のセッションに進む必要があります。