好きなクロスドメインCookie共有アプローチは何ですか？
私はiframe/p3pトリックが最も人気のあるものだと思っていますが、JavaScript +隠しフィールド+フレームが実際にハックジョブのように見えるため、個人的には気に入らないのです。また、Webサービスを使用して通信するマスタースレーブアプローチにも遭遇しました（ http://www.15seconds.com/issue/971108.htm ）。ユーザーには透過的であるため、より良いようですまた、さまざまなブラウザに対して堅牢です。
より良いアプローチはありますか、それぞれの長所と短所は何ですか？
私のアプローチでは、1つのドメインを「中央」ドメインとして指定し、他のドメインを「衛星」ドメインとして指定します。
誰かが「サインイン」リンクをクリックする（または永続的なログインCookieを提示する）と、サインインフォームは最終的に中央ドメインにあるURLにデータを送信します。便宜上、ユーザーは後でリダイレクトされます）。
次に、中央ドメインのこのページは、セッションCookieを設定し（ログインが成功した場合）、ユーザーがログインしたドメインにリダイレクトし、そのセッションに固有のURLに特別に生成されたトークンを使用します。
次に、サテライトURLのページは、そのトークンをチェックして、それがセッション用に生成されたトークンに対応するかどうかを確認し、対応する場合は、トークンなしで自身にリダイレクトし、ローカルCookieを設定します。これで、サテライトドメインにもセッションCookieが追加されました。このリダイレクトによりURLからトークンがクリアされるため、ユーザーまたはクローラーがそのトークンを含むURLを記録することはほとんどありません（そうした場合でも、トークンは使い捨てのトークンでもかまいません）。
これで、ユーザーは中央ドメインとサテライトドメインの両方でセッションCookieを取得しました。しかし、彼らが別の衛星を訪問したらどうなるでしょうか？まあ、通常、それらは認証されていないものとして衛星に表示されます。
ただし、アプリケーション全体を通して、ユーザーが有効なセッションにいるときは常に、他のサテライトドメインのページへのすべてのリンクに？または＆が付加されています。この 's'クエリ文字列は、「このユーザーにはセッションがあると考えているため、中央サーバーに確認する」という意味で予約しています。つまり、トークンやセッションIDはHTMLページに表示されず、誰かを識別できない文字「s」のみが表示されます。
そのような 's'クエリタグを受信するURLは、有効なセッションがまだない場合、「これが誰であるか教えてくれますか？」と言って中央ドメインにリダイレクトします。クエリ文字列に何かを入れることによって。
ユーザーが中央サーバーに到着したときに認証された場合、中央サーバーは単にセッションCookieを受信します。次に、別のシングルユーストークンを使用してユーザーをサテライトに送り返します。サテライトは、ログイン後、サテライトと同様に扱います（上記を参照）。つまり、サテライトはそのドメインにセッションCookieを設定し、それ自体にリダイレクトして、クエリ文字列からトークンを削除します。
私のソリューションは、スクリプトまたはiframeサポートなしで機能します。ユーザーがそのURLでCookieをまだ持っていない可能性があるクロスドメインURLに「？s」を追加する必要があります。私はこれを回避する方法を考えました：ユーザーが最初にログインするときに、すべての単一ドメインの周りにリダイレクトのチェーンを設定し、それぞれにセッションCookieを設定します。私がこれを実装していない唯一の理由は、これらのリダイレクトが発生する順序と停止するタイミングを設定できる必要があり、15ドメイン以上に拡張できないようにするために複雑になることです。 （あまりに多くなりすぎると、多くのブラウザやプロキシの「リダイレクト制限」に危険なほど近くなります）。
すべてのドメインバックエンドを完全に制御できる場合、これは良い解決策です。私の状況では、1つのクライアント（javascript/html）コントロールと別のフルコントロールしか持っていないため、:(を吸うiframe/p3pメソッドを使用する必要があります。
@thomasrutter
Ajax呼び出しを実行して、ページのロード時に「中央」ドメインの認証ステータスを確認することで、サテライトのすべてのアウトバウンドリンクを管理する必要がなくなります（クエリ文字列に「s」を追加します）。セッションごとに1つだけ行うことで、（後続のページのロードで）冗長な呼び出しを回避できます。
（a）セッションへのアクセスがより効率的になり、（b）ページのレンダリング時にユーザーがログインしているかどうかがわかるように、ページをロードする前にサーバー側で認証チェックリクエストを作成する方が間違いなく良いでしょう（それに応じてコンテンツを表示します）。
この記事の例は、基本的にURLにリダイレクトするURLにリダイレクトするため、疑わしいようです。クエリストリングで変数をドメインに返します。
この例では、悪意のあるユーザーが http://slave.com/return.asp?Return=blah&UID=12 "に移動し、ユーザーとしてslave.comにログインできることを意味します123。
私は何かが足りないのですか、それともこの手法が安全ではなく、使用すべきではないことはよく知られていますか？その例のようなもの（ユーザーIDを渡すことで、おそらくIDを移植可能にするため）。
また、ドメインb、c、d、...に対してアクティブなセッション情報を検証する必要があります。この方法では、ユーザーがドメインaにすでにログインしている場合にのみログインできます。
私たちはCookieチェーンを使用していますが、ドメインの1つがユーザーに対して機能しない場合（フィルタリングやファイアウォールなどが原因で）機能しなくなるため、これは適切な解決策ではありません。新しい手法（あなたのものを含む）は、Cookieを配布またはログインを管理する「マスター」サーバーが壊れた場合にのみ壊れます。
Return.aspが悪用されて任意のサイトにリダイレクトされる可能性があることに注意してください（たとえば this を参照）。
解決策を見つけたようです。Cookieを設定/取得するドメインのsrcをロードするスクリプトタグを作成できます。これまでのところ、SafariのみがCookieを設定できないようですが、Ie6とFF正常に動作します... Cookieを取得するだけの場合は、これは非常に良い方法です。