java - JD シングル サインオン認証に関する質問

Question

上の図は、JD.com のシングルポイント認証プロセス中の http リクエストです。

プロセスは次のとおりです。つまり、現在のホームページは www.jd.com であり、クロスドメイン要求を開始することによって sso.jd.hk に対する認証が開始されます。このリクエストには Cookie が含まれており、応答でも Cookie が返されます。応答で返される Cookie のドミナは、第 1 レベルのドメイン名に設定されます。

理解できない質問がいくつかあります。

(1) これはクロスドメイン リクエストですが、リクエストに Cookie が含まれるのはなぜですか?これでいいですか？他の友達がクッキーは持ち運べると言っているのを見ました。

例: http://blog.csdn.net/wzl002/a... クロスドメイン Ajax リクエストに Cookie 設定を含めるかどうか

しかし、具体的には JD.com について、彼はどのように対処したのでしょうか?

(2) 応答に Cookie が設定されていますが、現在のドメイン名は jd.hk ではなく www.jd.com です。これは設定できますか?
Jingdong の具体的な方法

(3) レスポンスにp3pが設定されていますが、これで質問2の問題は実現されますか？

(4) p3p は http://blog.csdn.net/ghj1976/...

を参照できます。

言及されている記事:
P3P を採用した後、Web サイトが個人を特定できる情報を収集しているかどうか、この情報を使用してユーザー プロファイルを作成しているか、訪問者がデータ収集を拒否できるかどうかを自動的に検出するようにブラウザを設定できます。
P3P 対応ブラウザには、選択できるデフォルトのオプションがいくつかあります。または、どのデータを共有するか、どの種類の Cookie を受け入れるかなどの質問に答えて、設定をカスタマイズすることもできます。ユーザーが Web を閲覧すると、このソフトウェアはユーザーのプライバシー設定が Web サイトのデータ収集慣行と一致するかどうかを判断します。

私の理解は次のとおりです: p3p 機能を備えたブラウザは、ドメインを越えた Cookie の書き込みを検出し、ユーザーと対話することで、ドメインを越えて Cookie を書き込むことに同意するかどうかをユーザーに尋ねます。頻繁に発生する Web ページ変更プロンプト インタラクションと同様ですか? ? ? ?この理解は不合理に思えます、

一言お願いします (＾-＾)

Answer 1

1. ドメイン名とホストの違いを理解します。たとえば、www.jd.com はドメイン名ではなくホスト名であり、jd.com はドメイン名です。下の図では、hostOnly がチェックされている場合、この Cookie はこのホストでのみ機能します。ホスト名 www1.jd.com の変更は機能しません。ただし、hostOnly がチェックされていない場合、この Cookie はこのドメイン名のどのホストでも有効です。この Cookie が www.jd.com で作成された場合でも、この Cookie は www1.jd.com で読み取ることができます。 、ブラウザが www1.jd.com にアクセスすると、この Cookie がリクエストの一部としてサーバーに送信されます。

1. Ajax クロスドメインはこれとは異なります。 Ajax では、ドメイン名とホストの違いが混同されています。 Ajax の観点からは、リクエストが同じホスト上で開始されない限り、リクエストはクロスドメインとみなされます。たとえば、www.jd.com から ajax リクエストを開始して www1.jd.com のコンテンツにアクセスする場合、これもクロスドメインとみなされます。厳密に言えば、これはクロスホストとしてのみカウントされ、クロスドメインとしてカウントされません。ただし、歴史的な理由により、常にこのように定義されているため、修正する方法はありません。

Answer 2

私の提案は、トークンの検証方法を自分で設計することです。Cookie と http リクエストの応答は、トークンを渡すための単なる手段です。このトークンを redis/memcached に保存すると、すべてのノードがトークンを介して現在のステータス (検証済みかどうか) をクエリしたり、同じ理由で検証を提供する独立したサービスを作成したりできます。 sso.jd.hk は Cookie を使用して検証トークンやタイムスタンプなどの情報を保存します。

トークンを秘密にする必要はありません。トークンを直接返信してください。このモードは WebSocket 認証にも適しています。

一般的に使用される計算方法:token = sha1(数据ID+过期时间戳+验证密码)

トークン、データ ID、有効期限タイムスタンプをクライアントに送信し、他のサービスにリクエストを送信するときにこれら 3 つの情報を添付します。検証パスワードを知っているのはサーバーだけであるため、リクエストが別のサービスからのものであるかどうかを検証できます。 AWS リソースの検証方法はこれと似ていますが、検証パスワードが API キーに置き換えられる点が異なります。