非永続化ロードバランサーでのCookieの動作


7

ssoを使用してユーザーをログインさせるDrupalアプリケーションがあります。

AWSクラシックロードバランサー(ELB)を使用しています。AWSは、ELBにセッション永続性がないことを通知しています。

私が理解しようとしているのは、Cookieが従来のロードバランサーで非永続性でどのように機能するかです。

example.com DNSはELBを指しています。プールServer1とServer2には2つのサーバーがあります

ユーザーhttp://example.com/user/12345/がまだログインしていない場合にサーバー1のホームページhttp://example.com/user/login/ssoにアクセスすると、ssoページにリダイレクトされ、自動的にログインしてCookieが取得され、SESS<hexnumber>次にリダイレクトされます。http://example.com/user/12345/

セッションサーバー(redis)を追加することはできません。どちらのリダイレクトでも、サーバー1に留まることが保証されます。

私の知る限り、「example.com」にヒットするたびに、ユーザーはサーバー1またはサーバー2のいずれかに到達する可能性があります。

私の質問:

server1でcookieを取得してからserver2にリダイレクトされた場合、cookieがserver1のそのユーザーに既に割り当てられていることをserver2はどのようにして知るのでしょうか。

まるで自分のことを考えているようです。セッションの永続性なしでLBを使用して過去にこのタイプのセットアップを行ったとき、私たちはセッションを保持するためにredisサーバーを使用し、各リクエストはセッション情報のredisサーバーを調べました。

回答:


3

Cookieはサーバーではなくブラウザで設定されます。ドメインと、オプションでURL内の特定のパスに制限されているため、両方のサーバーが同じドメインからアクセスされている限り、Cookieはそこにあります。

Cookieがセッションを指している場合、server1とserver2の両方が何らかの方法でそのセッションにアクセスできる必要があります。サーバー間でセッションを共有できない場合は、ユーザーを特定のサーバーに常駐させる必要があります。これは、DNSと少しのURL書き換えマジックで簡単に実現できます。

  • www.example.comは両方のサーバーを指します。
  • www1.example.comはserver1のみを指します
  • www2.example.comはserver2のみを指します

一連のsimple(ish)書き換えルールとCookieを使用して、ユーザーを特定のサーバーにロックし、セッションが持続するようにします。

詳細は次のとおりです。

DNS:

  • example.com A 1.1.1.1、A 2.2.2.2
  • www.example.com CNAME example.com
  • www1.example.com A 1.1.1.1
  • www2.example.com A 2.2.2.2

書き換えルール:

  • 永続化Cookie:「バックエンド」
  • 初期接続:「バックエンド」が定義されていない場合は、「バックエンド」をwww1またはwww2に設定します。これは、応答したサーバーに応じて、そのサーバーにリダイレクトします。cookieはドメイン「example.com」に設定する必要があります。これにより、www1とwww2の両方にロードされます。
  • 「バックエンド」が定義されている場合は、その値がサーバーインスタンスと一致していることを確認し、必要に応じてリダイレクトします。
  • セッションCookieがサーバーの完全なドメイン名(www1.example.comまたはwww2.example.com)で定義されていることを確認します

書き換えロジックは、Webサーバー自体で定義されます。最近のすべてのWebサーバーには、この機能を完全に実装できる非常に特徴的な書き換え言語があります。


example1.comとexample2.comについて考えましたが、example1.comまたはexample2.comを使用する必要があることをユーザーに伝えることは許可されていません。これは、Cookieとブラウザがどのように機能するかを明確に理解していないと考えられたため、顔を保存して、なんらかのバックエンドの魔法を起こします。example.comユーザーがCookieを取得して、www1.example.comまたはwww2.example.comに保持している場合、どのように使用できますか?
Donna Delour 2018年

私は私の答えを更新しました

0

Elasticache Redisのようなセッション管理データベースを使用できない場合(単なるセッションのRedisは月額$ 15を超えるべきではありません)、次に最適なオプションはELBでスティッキーセッションを有効にすることです。

https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html

これにより、ユーザーはセッション全体を通じて同じバックエンドノードに移動する必要があります。ライフタイムが900秒の「ロードバランサーによって生成されたCookie」で十分ですが、これは微調整できます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.