お気に入りのクロスドメインCookie共有アプローチは何ですか？

Question

iframe / p3pトリックは最も人気のあるものですが、javascript +隠しフィールド+フレームが実際にハックジョブのように見えるため、個人的には好きではありません。また、Webサービスを使用して通信するマスタースレーブアプローチに出会いました（ http：// www。 15seconds.com/issue/971108.htm ）を使用します。ユーザーにとって透過的であり、さまざまなブラウザに対して堅牢であるため、より良いようです。

より良いアプローチはありますか？また、それぞれの長所と短所は何ですか？

Answer 1

私のアプローチでは、1つのドメインを「中央」ドメインとして指定し、他のドメインを「サテライト」ドメインとして指定します。

誰かが「サインイン」リンクをクリックする（または永続的なログインCookieを提示する）と、サインインフォームは最終的に中央ドメイン上のURLにデータを送信します。 from（便宜のため、ユーザーはその後リダイレクトされます）。

中央ドメインのこのページは、セッションCookieの設定（ログインが成功した場合）に進み、そのセッションに固有のURLに特別に生成されたトークンを使用して、ユーザーがログインしたドメインにリダイレクトします。

サテライトURLのページは、そのトークンをチェックして、セッション用に生成されたトークンに対応するかどうかを確認し、対応する場合は、トークンなしで自分自身にリダイレクトし、ローカルCookieを設定します。これで、サテライトドメインにもセッションCookieがあります。このリダイレクトはURLからトークンをクリアするため、ユーザーまたは任意のクローラーがそのトークンを含むURLを記録することはほとんどありません（そうであったとしても、トークンは使い捨てトークンであってもかまいません）。

現在、ユーザーは中央ドメインとサテライトドメインの両方でセッションCookieを持っています。しかし、彼らが別の衛星を訪れたらどうなるでしょうか？まあ、通常、それらは衛星からは認証されていないように見えます。

ただし、アプリケーション全体で、ユーザーが有効なセッションにいるときはいつでも、他のサテライトドメインのページへのすべてのリンクに？sまたは＆amp;が追加されています。この「s」クエリ文字列は、「このユーザーにはセッションがあることを考慮しているため、中央サーバーで確認する」ことを意味します。つまり、HTMLページにはトークンまたはセッションIDは表示されず、誰かを特定できない文字「s」のみが表示されます。

このような 's'クエリタグを受信するURLは、有効なセッションがまだない場合、「これが誰なのか教えてください」と言って中央ドメインにリダイレクトします。クエリ文字列に何かを入れることで。

ユーザーが中央サーバーに到着すると、そこで認証された場合、中央サーバーは単にセッションCookieを受信します。次に、別の使い捨てトークンを使用してユーザーをサテライトに送り返します。サテライトは、ログイン後のサテライトと同様に処理します（上記を参照）。つまり、サテライトはそのドメインでセッションCookieを設定し、それ自体にリダイレクトしてクエリ文字列からトークンを削除します。

私のソリューションは、スクリプトやiframeサポートなしで機能します。ユーザーがまだそのURLにCookieを持っていないクロスドメインURLに「？s」を追加する必要があります。これを回避する方法を考えました。ユーザーが最初にログインしたときに、すべての単一ドメインの周りにリダイレクトのチェーンを設定し、各ドメインにセッションCookieを設定します。私がこれを実装していない唯一の理由は、これらのリダイレクトが発生するタイミングと停止する順序を設定する必要があり、15ドメインなどを超えて展開できないようにするために複雑になるためです（多すぎると、多くのブラウザやプロキシの「リダイレクト制限」に危険なほど近づきます。）

Answer 2

これは、すべてのドメインバックエンドを完全に制御できる場合に適したソリューションです。私の状況では、一方のクライアント（javascript / html）コントロールともう一方のフルコントロールしか持っていないため、iframe / p3pメソッドを使用する必要があります。これは：（。

Answer 3

この記事の例は、基本的にURLにリダイレクトし、そのURLがクエリ文字列で変数をドメインに返すため、私には疑わしいようです。

この例では、悪意のあるユーザーが単に httpに移動できることを意味します。 //slave.com/return.asp?Return=blah&UID=123 ＆quot;ユーザー123としてslave.comにログインします。

何かが足りない、またはこの手法が安全ではなく、その例が示すように使用されるべきではないことはよく知られていますか（おそらく、ユーザーIDを渡して、おそらく身元を携帯できるようにするため）。

Answer 4

@thomasrutter

サテライト上のすべてのアウトバウンドリンクを管理する必要はありません（クエリ文字列に＆quot; s＆quot;を追加することにより）。セッションごとに1つだけを作成することにより、（以降のページの読み込みで）冗長な呼び出しを回避できます。

（a）セッションへのアクセスがより効率的になり、（b）ページのレンダリング時にユーザーがログイン（およびそれに応じてコンテンツを表示）。

Answer 5

Cookieチェーンを使用しますが、ドメインの1つがユーザーに対して機能しない場合（フィルタリング/ファイアウォールなどが原因）破損するため、これは適切なソリューションではありません。新しいテクニック（あなたのものを含む）は、「マスター」 Cookieを配布する/ログインの中断を管理するサーバー。

return.aspを悪用して任意のサイトにリダイレクトできることに注意してください（ this など）。

Answer 6

OKつまり、Cookieを取得するだけの場合は、これは非常に優れたアプローチです。

Answer 7

また、アクティブなセッション情報をドメインb、c、dに対して検証する必要があります。この方法では、ユーザーがドメインaですでにログインしている場合にのみログインできます。

Answer 8

変数を受け取るドメインで行うことは、リファラーアドレスもチェックするため、リンクがアドレスバーに単純に入力されるのではなく、自分のドメインからのものであることを確認できます。このアプローチはうまく機能します。