ドメイン間リソース共有のいくつかの方法
5544 ワード
JavaScriptやActionScriptのようなクライアントプログラミング言語では、同源ポリシーは重要なセキュリティ理念であり、データのセキュリティを保証する上で重要な意義を持っています.同源ポリシーは、ドメイン間のスクリプトが分離されていることを規定し、1つのドメインのスクリプトが別のドメインのほとんどの属性と方法にアクセスおよび操作できないことを規定します.では、同じドメインとは何ですか.異なるドメインとは何ですか.2つのドメインが同じプロトコル(httpなど)、同じポート(80など)、同じhostを有する場合(www.example.orgなど)では、同じドメインと考えられます.たとえば、http://www.example.org/index.htmlおよびhttp://www.example.org/sub/index.html同じドメインであり、http://www.example.org, https://www.example.org, http://www.example.org:8080, http://sub.example.orgいずれもドメイン間で構成されます.同源ポリシーは、いくつかの特殊な状況にも対応する必要があります.ファイルプロトコルの下でスクリプトへのアクセスを制限するなどの処理を行います.ローカルのHTMLファイルはブラウザでfileプロトコルで開かれていますが、スクリプトがfileプロトコルでハードディスク上の他の任意のファイルにアクセスできれば、セキュリティ上の危険性があります.現在、IE 8にはこのような隠れた危険性があります.
同源戦略の影響を受けると、ドメイン間リソースの共有は制約されます.しかし、人々の実践とブラウザの進歩に伴い、現在、ドメイン間リクエストのテクニックには、貴重な経験の沈殿と蓄積がたくさんあります.ここでは、ドメイン間リソースの共有を2つに分けます.1つは単一のデータリクエストであり、もう1つは双方向のメッセージ通信です.次に、一般的ないくつかのドメイン間方式では、以下のドメイン間インスタンスのソースコードをここから得ることができます.
たんほうこうたいいき
JSONP
JSONP (JSON with Padding)簡単で効率的なドメイン間方式であり、HTMLのscriptタグは他のドメインのJavaScriptをロードして実行することができるので、scriptタグで他のドメインのリソースを動的にロードすることができます.例えば、ドメインAのページpageAからドメインBのデータをロードすると、ドメインBのページpageBでJavaScriptの形式でpageAに必要なデータを宣言し、pageAでscriptタグを使用します署名してpageBをロードすると、pageBのスクリプトが実行されます.JSONPはこれにコールバック関数を加え、pageBのロードが完了するとpageAで定義された関数が実行され、必要なデータがパラメータとしてこの関数に渡されます.JSONPは実現しやすいですが、第三者のスクリプトが勝手に実行されると、セキュリティ上の危険性もあります.ページの内容を改ざんし、機密データをキャプチャします.しかし、信頼されている双方でデータを転送するには、JSONPが適切です.
Flash URLLoader
Flashには独自のセキュリティポリシーがあり、サーバはcrossdomain.xmlファイルを通じてどのドメインのSWFファイルにアクセスできるかを宣言し、SWFはAPIを通じて自身がどのドメインのSWFにロードできるかを決定することができる.ドメイン間でリソースにアクセスする場合、例えばドメインwww.a.comからドメインwww.b.com上のデータを要求すると、Flashを利用してHTTP要求を送信することができる.まず、ドメインwww.b.com上ののcrossdomain.xml(一般的にはルートディレクトリに格納されており、手動で作成する必要がない場合)は、www.a.comをホワイトリストに追加します.次に、Flash URLLoaderでHTTPリクエストを送信し、最後にFlash APIで応答結果をJavaScriptに渡します.Flash URLLoaderは一般的なドメイン間ソリューションですが、iOSをサポートする必要がある場合は、このソリューションはどうしようもありません.
Access Control
Access Controlは比較的超越的なドメイン間方式であり、現在は少ないブラウザでしかサポートされていない.これらのブラウザはドメイン間HTTPリクエスト(Firefox,Google ChromeなどはXMLHTTPRequestで実現され、IE 8ではXDomainRequestで実現される)を送信することができる.要求された応答は、要求ドメインのアクセス権を宣言するAccess-Control-Allow-OriginのHTTP応答ヘッダを含む必要があります.例えば、www.a.comがwww.b.comの下のasset.phpに対してドメイン間HTTP要求を送信した場合、asset.phpは次の応答ヘッダを追加する必要があります.
window.name
Windowsオブジェクトのname属性は特別な属性であり、そのwindowのlocationが変化し、再ロードされると、そのname属性は依然として変わらないことができる.それでは、ページAでiframeで他のドメインのページBをロードし、ページBでJavaScriptで渡すデータをwindow.nameに割り当て、iframeロードが完了した後、ページAでiframeのアドレスを変更することができるを選択し、それを同じドメインのアドレスにしてwindow.nameの値を読み出すことができます.この方法は一方向のデータ要求に非常に適しており、プロトコルが簡単で安全です.JSONPのように外部スクリプトを制限なく実行することはありません.
server proxy
データプロバイダがJSONPプロトコルまたはwindow.nameプロトコルのサポートを提供していない場合、他のドメインにアクセス権を開放していない場合、server proxyの方法でデータをキャプチャすることができます.例えば、www.a.comドメインの下のページがwww.b.comの下のリソースファイルasset.txtを要求する必要がある場合、www.b.com/asset.txtを指すajaxリクエストを直接送信するとブラウザによって要求されるに違いありません.ブロックします.この場合、www.a.comの下にエージェントを配置し、ajaxリクエストをこのエージェントパスの下、例えばwww.a.com/proxy/にバインドします.その後、このエージェントはHTTPリクエストを送信してwww.b.comの下のasset.txtにアクセスします.ドメイン間のHTTPリクエストはサーバ側で行われ、ゲスト側はドメイン間ajaxリクエストを生成しません.このドメイン間方式では、ターゲットリソースとプロトコルを締結する必要はありません.また、他人の使用を制限したり、使用頻度を制限したりするなど、実践的にこのエージェントをある程度保護すべきであることに注意しなければならない.
双方向ドメイン間
document.domain
documentのdomainプロパティを変更することで、ドメインとサブドメインまたは異なるサブドメイン間で通信できます.同ドメインポリシーでは、www.a.comやsub.a.comなど、ドメインとサブドメインが異なるドメインに属していると考えられています.この場合、sub.a.comで定義されているJavaScriptメソッドをwww.a.comの下のページで呼び出すことはできません.ただし、documentのdomainプロパティを変更するとa.comに変更すると、ブラウザは同じドメインの下にあると判断し、お互いに相手のmethodを呼び出して通信することができます.
FIM – Fragment Identitier Messaging
異なるドメイン間でJavaScriptは限られたアクセスと操作しかできませんが、実際にはこれらの限られたアクセス権限を利用してドメイン間通信の目的を達成することができます.FIM(Fragment Identier Messaging)この大前提の下で発明されたものである.親ウィンドウはiframeに対してURL読み書きを行うことができ、iframeは親ウィンドウのURLを読み書きすることもできる.URLの一部はfragと呼ばれ、番号とその後ろの文字である.それは一般的にブラウザのアンカー位置付けに用いられ、Server端はこの部分に関心を持たず、HTTPリクエスト中にfragを携帯しないと言うべきである.したがって、この部分の修正はHTTPを生成しない要求されますが、ブラウザ履歴が生成されます.FIMの原理は、URLのfrag部分を変更して双方向通信を行うことです.各windowは、他のwindowのlocationを変更することによってメッセージを送信し、自分のURLの変化を傍受することによってメッセージを受信します.このような通信は、不要なブラウザ履歴をもたらし、onhashchangeをサポートしないブラウザもあります件、URLの変更を知るためにポーリングが必要で、最後に、URLはブラウザの下で長さの制限があって、これは毎回伝送するデータの量を制約しました.
Flash LocalConnection
ページ上の双方向通信はFlashによって解決することもでき、Flash APIにはLocalConnectionというクラスがあり、このクラスは2つのSWFの間でプロセス通信を行うことができ、このときSWFは独立したFlash PlayerまたはAIRに再生することができ、HTMLページまたはPDFに埋め込むことができる.この通信原則に従って、異なるドメインのHTMLページにそれぞれ1つのSWFをネストして互いに達成することができるデータの転送の目的です.SWFはLocalConnectionでデータを交換するのは早いですが、毎回のデータ量は40 kbのサイズ制限があります.この方式ではドメイン間通信が複雑すぎて、しかも2つのSWFファイルが必要で、実用性は強くありません.
window.postMessage
Windows.postMessageはHTML 5で定義された新しい方法で、Windowsをまたいで通信するのに便利です.新しい方法なので、古いブラウザでも古いブラウザでも使えません.
Cross Frame
Cross FrameはFIMの変種で、空白のiframeを借りて、余分なブラウザ履歴を生成することもなく、URLの変更をポーリングする必要もなく、可用性と性能の面で大きな変化を遂げた.その基本原理は大体このようなもので、ドメインwww.a.comにページA.htmlと空白のエージェントページproxyA.htmlがあり、もう一つのドメインwww.b.comにはページB.htmlと空白エージェントページproxyB.html、A.htmlがB.htmlにメッセージを送信する必要がある場合、ページは非表示のiframeを作成し、iframeのsrcはproxyB.htmlを指し、messageをURL fragとし、B.htmlとproxyB.htmlは同ドメインであるため、iframeのロードが完了した後、B.htmlはiframeのURLを取得し、messageを解析し、iframeを削除することができる..htmlはA.htmlにメッセージを送信する必要がある場合、原理は同じです.Cross Frameは双方向通信方式がよく、安全で効率的ですが、Operaでは使用できませんが、Operaの下ではより簡単なwindow.postMessageを使って代用することができます.
まとめ
ドメインをまたぐ方法は多く、異なるアプリケーションシーンで最適なソリューションを見つけることができます.例えば、一方向のデータ要求では、JSONPまたはwindow.nameを優先的に選択する必要があります.双方向通信ではCross Frameを採用しています.データプロバイダと通信プロトコルが成立していない場合でも、server proxyでデータをキャプチャすることができます.
(変換元http://ued.koubei.com/?p=1291)
同源戦略の影響を受けると、ドメイン間リソースの共有は制約されます.しかし、人々の実践とブラウザの進歩に伴い、現在、ドメイン間リクエストのテクニックには、貴重な経験の沈殿と蓄積がたくさんあります.ここでは、ドメイン間リソースの共有を2つに分けます.1つは単一のデータリクエストであり、もう1つは双方向のメッセージ通信です.次に、一般的ないくつかのドメイン間方式では、以下のドメイン間インスタンスのソースコードをここから得ることができます.
たんほうこうたいいき
JSONP
JSONP (JSON with Padding)簡単で効率的なドメイン間方式であり、HTMLのscriptタグは他のドメインのJavaScriptをロードして実行することができるので、scriptタグで他のドメインのリソースを動的にロードすることができます.例えば、ドメインAのページpageAからドメインBのデータをロードすると、ドメインBのページpageBでJavaScriptの形式でpageAに必要なデータを宣言し、pageAでscriptタグを使用します署名してpageBをロードすると、pageBのスクリプトが実行されます.JSONPはこれにコールバック関数を加え、pageBのロードが完了するとpageAで定義された関数が実行され、必要なデータがパラメータとしてこの関数に渡されます.JSONPは実現しやすいですが、第三者のスクリプトが勝手に実行されると、セキュリティ上の危険性もあります.ページの内容を改ざんし、機密データをキャプチャします.しかし、信頼されている双方でデータを転送するには、JSONPが適切です.
Flash URLLoader
Flashには独自のセキュリティポリシーがあり、サーバはcrossdomain.xmlファイルを通じてどのドメインのSWFファイルにアクセスできるかを宣言し、SWFはAPIを通じて自身がどのドメインのSWFにロードできるかを決定することができる.ドメイン間でリソースにアクセスする場合、例えばドメインwww.a.comからドメインwww.b.com上のデータを要求すると、Flashを利用してHTTP要求を送信することができる.まず、ドメインwww.b.com上ののcrossdomain.xml(一般的にはルートディレクトリに格納されており、手動で作成する必要がない場合)は、www.a.comをホワイトリストに追加します.次に、Flash URLLoaderでHTTPリクエストを送信し、最後にFlash APIで応答結果をJavaScriptに渡します.Flash URLLoaderは一般的なドメイン間ソリューションですが、iOSをサポートする必要がある場合は、このソリューションはどうしようもありません.
Access Control
Access Controlは比較的超越的なドメイン間方式であり、現在は少ないブラウザでしかサポートされていない.これらのブラウザはドメイン間HTTPリクエスト(Firefox,Google ChromeなどはXMLHTTPRequestで実現され、IE 8ではXDomainRequestで実現される)を送信することができる.要求された応答は、要求ドメインのアクセス権を宣言するAccess-Control-Allow-OriginのHTTP応答ヘッダを含む必要があります.例えば、www.a.comがwww.b.comの下のasset.phpに対してドメイン間HTTP要求を送信した場合、asset.phpは次の応答ヘッダを追加する必要があります.
header("Access-Control-Allow-Origin: http://www.a.com");window.name
Windowsオブジェクトのname属性は特別な属性であり、そのwindowのlocationが変化し、再ロードされると、そのname属性は依然として変わらないことができる.それでは、ページAでiframeで他のドメインのページBをロードし、ページBでJavaScriptで渡すデータをwindow.nameに割り当て、iframeロードが完了した後、ページAでiframeのアドレスを変更することができるを選択し、それを同じドメインのアドレスにしてwindow.nameの値を読み出すことができます.この方法は一方向のデータ要求に非常に適しており、プロトコルが簡単で安全です.JSONPのように外部スクリプトを制限なく実行することはありません.
server proxy
データプロバイダがJSONPプロトコルまたはwindow.nameプロトコルのサポートを提供していない場合、他のドメインにアクセス権を開放していない場合、server proxyの方法でデータをキャプチャすることができます.例えば、www.a.comドメインの下のページがwww.b.comの下のリソースファイルasset.txtを要求する必要がある場合、www.b.com/asset.txtを指すajaxリクエストを直接送信するとブラウザによって要求されるに違いありません.ブロックします.この場合、www.a.comの下にエージェントを配置し、ajaxリクエストをこのエージェントパスの下、例えばwww.a.com/proxy/にバインドします.その後、このエージェントはHTTPリクエストを送信してwww.b.comの下のasset.txtにアクセスします.ドメイン間のHTTPリクエストはサーバ側で行われ、ゲスト側はドメイン間ajaxリクエストを生成しません.このドメイン間方式では、ターゲットリソースとプロトコルを締結する必要はありません.また、他人の使用を制限したり、使用頻度を制限したりするなど、実践的にこのエージェントをある程度保護すべきであることに注意しなければならない.
双方向ドメイン間
document.domain
documentのdomainプロパティを変更することで、ドメインとサブドメインまたは異なるサブドメイン間で通信できます.同ドメインポリシーでは、www.a.comやsub.a.comなど、ドメインとサブドメインが異なるドメインに属していると考えられています.この場合、sub.a.comで定義されているJavaScriptメソッドをwww.a.comの下のページで呼び出すことはできません.ただし、documentのdomainプロパティを変更するとa.comに変更すると、ブラウザは同じドメインの下にあると判断し、お互いに相手のmethodを呼び出して通信することができます.
FIM – Fragment Identitier Messaging
異なるドメイン間でJavaScriptは限られたアクセスと操作しかできませんが、実際にはこれらの限られたアクセス権限を利用してドメイン間通信の目的を達成することができます.FIM(Fragment Identier Messaging)この大前提の下で発明されたものである.親ウィンドウはiframeに対してURL読み書きを行うことができ、iframeは親ウィンドウのURLを読み書きすることもできる.URLの一部はfragと呼ばれ、番号とその後ろの文字である.それは一般的にブラウザのアンカー位置付けに用いられ、Server端はこの部分に関心を持たず、HTTPリクエスト中にfragを携帯しないと言うべきである.したがって、この部分の修正はHTTPを生成しない要求されますが、ブラウザ履歴が生成されます.FIMの原理は、URLのfrag部分を変更して双方向通信を行うことです.各windowは、他のwindowのlocationを変更することによってメッセージを送信し、自分のURLの変化を傍受することによってメッセージを受信します.このような通信は、不要なブラウザ履歴をもたらし、onhashchangeをサポートしないブラウザもあります件、URLの変更を知るためにポーリングが必要で、最後に、URLはブラウザの下で長さの制限があって、これは毎回伝送するデータの量を制約しました.
Flash LocalConnection
ページ上の双方向通信はFlashによって解決することもでき、Flash APIにはLocalConnectionというクラスがあり、このクラスは2つのSWFの間でプロセス通信を行うことができ、このときSWFは独立したFlash PlayerまたはAIRに再生することができ、HTMLページまたはPDFに埋め込むことができる.この通信原則に従って、異なるドメインのHTMLページにそれぞれ1つのSWFをネストして互いに達成することができるデータの転送の目的です.SWFはLocalConnectionでデータを交換するのは早いですが、毎回のデータ量は40 kbのサイズ制限があります.この方式ではドメイン間通信が複雑すぎて、しかも2つのSWFファイルが必要で、実用性は強くありません.
window.postMessage
Windows.postMessageはHTML 5で定義された新しい方法で、Windowsをまたいで通信するのに便利です.新しい方法なので、古いブラウザでも古いブラウザでも使えません.
Cross Frame
Cross FrameはFIMの変種で、空白のiframeを借りて、余分なブラウザ履歴を生成することもなく、URLの変更をポーリングする必要もなく、可用性と性能の面で大きな変化を遂げた.その基本原理は大体このようなもので、ドメインwww.a.comにページA.htmlと空白のエージェントページproxyA.htmlがあり、もう一つのドメインwww.b.comにはページB.htmlと空白エージェントページproxyB.html、A.htmlがB.htmlにメッセージを送信する必要がある場合、ページは非表示のiframeを作成し、iframeのsrcはproxyB.htmlを指し、messageをURL fragとし、B.htmlとproxyB.htmlは同ドメインであるため、iframeのロードが完了した後、B.htmlはiframeのURLを取得し、messageを解析し、iframeを削除することができる..htmlはA.htmlにメッセージを送信する必要がある場合、原理は同じです.Cross Frameは双方向通信方式がよく、安全で効率的ですが、Operaでは使用できませんが、Operaの下ではより簡単なwindow.postMessageを使って代用することができます.
まとめ
ドメインをまたぐ方法は多く、異なるアプリケーションシーンで最適なソリューションを見つけることができます.例えば、一方向のデータ要求では、JSONPまたはwindow.nameを優先的に選択する必要があります.双方向通信ではCross Frameを採用しています.データプロバイダと通信プロトコルが成立していない場合でも、server proxyでデータをキャプチャすることができます.
(変換元http://ued.koubei.com/?p=1291)