5

私が 2 つのドメインを管理しているwww.api_domain.comとしwww.website_domain.comます。www.api_domain.comユーザーに認証を要求し、セッション Cookie を使用してリクエストを行っているユーザーを認識する API を提供します。www.website_domain.comからそのページにスクリプトをロードし、そのスクリプトは、現在のユーザーの Cookie を使用して API URL を呼び出し、その結果を からのページで何らかの方法で使用しwww.api_domain.comたいと考えています。www.api_domain.comwww.website_domain.com

スクリプトを最初にロードする場合、またはユーザーのセッション Cookie を必要としない API URL の場合、最も簡単な解決策は単純に

Access-Control-Allow-Origin: http://www.website_domain.com

からの応答のヘッダーwww.api_domain.com。これは、IE 以外のすべてのブラウザーでそのまま使用できるようです。また、IE は、jQuery の AJAX メソッドを使用して作成された AJAX 要求の Allow-Origin ヘッダーを尊重しませんが、xdr.js のようなライブラリが舞台裏で何らかの魔法をかけて、 jQuery、IE、および Allow-Origin ヘッダーがうまく連携し、他のすべてのブラウザーと同じように動作するようにします (xdr.js の詳細はわかりませんが、私が見る限り、認証されていない要求に対しては完全に機能します) )。

http://www.api_domain.com問題は、ユーザーのセッション Cookie を必要とする URL にアクセスしたいときに発生します。この問題がブラウザーに依存しない設定で議論される場合、通常、2 つの解決策が提案されます。

  1. からの応答で使用Access-Control-Allow-Credentials: trueして、クロスドメイン要求でも Cookie が送信されるようにします。
  2. http://www.website_domain.comorigin を使用してページに iframe を作成し、2 つのウィンドウがHTML5 ポスト メッセージhttp://www.api_domain.comを使用して相互に通信し、リクエストを作成するすべての責任をiframe に委任します。http://www.api_domain.com

可能であれば、オプション 1 を使用することを強くお勧めしhttp://www.api_domain.comます。同じドメインの API に触れるように記述するのと同じ方法で、API を使用する Javascript コードを記述できるからです。iframe アプローチを使用するには、AJAX のような要求を iframe に送信するためのフレームワークを学習または作成する必要があり、成功およびエラー ハンドラーを使用します。また、iframe にロードするコードを作成する必要があることも意味します。これは、API URL をヒットするための薄いラッパーの全体のチャンクになります。最初のアプローチよりも醜く、トリッキーで、理解するのが難しいようです。

ただし、オプション 1 を IE で機能させる方法がわかりません。私はAccess-Control-Allow-Credentials: trueAPI URL を設定していますが、他のすべてのブラウザはそれらの URL に Cookie を送信しますが、IE 9 は xdr.js ライブラリを使用しても送信しません。(IE 8 ではテストしていません。) 他に報告すべき症状はありません。IE の開発者ツールで応答を表示すると、適切なヘッダーAccess-Control-Allow-Originとヘッダーが表示されますが、要求には Cookie ヘッダーがありません。Access-Control-Allow-Credentialswww.api_domain.com

Internet Explorerにヘッダーを尊重させるために使用できるハックまたは魔法の呪文Access-Control-Allow-Credentials、またはIEが認識する他のヘッダーを使用できますか?

4

2 に答える 2

9

XMLHttpRequest を使用した CORS がサポートされていないため、オプション 1 は IE9 以下では使用できません。さらに、XDomainRequest を使用しようとすると、リクエストとともに Cookie を送信できなくなります。私は、testswarm で使用する UI テスト ライブラリを作成する作業を何度か行ってきました。あなたがやりたいことは、その方法では不可能です。

以下は、元 Microsoft 開発者である Eric Law による投稿で、この問題について詳しく説明しています 。回避策.aspx

IE 8 および 9 では CORS リクエストを使用して Cookie を送信できないことを明確にする関連セクションは次のとおりです。

Internet Explorer 8 では、XDomainRequest オブジェクトが導入されました。このオブジェクトを使用すると、データ ソースが応答が公開されていることを示している場合にのみ HTTP 応答を現在のページで読み取ることができるようにすることで、AJAX アプリケーションは安全なクロスオリジン要求を直接行うことができます。このようにして、Same Origin Policy のセキュリティ保証が保護されます。応答は、Access-Control-Allow-Origin HTTP 応答ヘッダーに値 *、または呼び出しページの正確なオリジンを含めることにより、クロスドメイン アクセスを許可する意思があることを示します。

新しいオブジェクトを設計するとき、既存のサイトやサービスが危険にさらされないようにすることが最優先事項でした。そのために、XDomainRequest オブジェクトで作成できるリクエストの種類にいくつかの制限を課しました。

...

5: リクエストとともに認証または Cookie は送信されません。

ユーザーのアンビエント オーソリティ (Cookie、HTTP 資格情報、クライアント証明書など) の誤用を防ぐために、要求から Cookie と資格情報が削除され、HTTP 応答の認証チャレンジまたは Set-Cookie ディレクティブが無視されます。一部の Windows 認証プロトコル (NTLM/Kerberos など) は要求ベースではなく接続ベースであるため、XDomainRequests は以前に認証された接続では送信されません。

クロスオリジン要求に対してユーザーの認証を実行したいサイトは、明示的な方法 (POST 本文または URL のトークンなど) を使用して、ユーザーの周囲の権限を危険にさらすことなく、この認証情報を渡すことができます。

両方の場所を制御していると仮定すると、おそらくサーバー間認証プロセスを作成し、ドメインから提供された種類のセッション ID を他のドメインに渡し、クライアントが実際にリクエストを介してアクセスしているドメインに渡すことができます。きれいではありませんが、機能します。この方法は記事でも紹介されています。ただし、セッション ハイジャックの可能性が生じるため、注意が必要です。

于 2013-03-10T09:13:15.430 に答える
0

XMLHttpRequestIE8+ には、資格情報をサポートする代替手段がありXDomainRequestます。とにかく、XDomainRequestが提供する機能よりも機能が少ないため、JQuery によって実装されていませんが、必要なものを提供するjQuery CORS PluginXMLHttpRequestのようなプラグインがあります。

クロス オリジン リソース シェアリング (CORS) をブラウザー (IE8+ を含む) 間で透過的に追加する jQuery プラグイン。これにより、Cookie とヘッダーをサポートするクロスドメイン Ajax リクエストが可能になります。

また、IEがのようなヘッダーでワイルドカードをサポートしていないと思いますが、よくわかりませんAccess-Control-Allow-Origin: *

于 2013-03-09T22:10:42.693 に答える