問題タブ [same-origin-policy]

私は自分のウェブページにいるのか、ユーザーがいるのかを知っています：http: //www.example.com/form.php

そして私はそのページから次のアドレスにajaxリクエストを行います： http ：//example.com/responder.php

同一生成元ポリシー（サブドメインが異なる）のために失敗します。

私が理解しようとしているのは、リクエストとサーバーが明らかに異なる場合に、AJAXリクエストがflickrのようなAPIからデータをプルできるのはどうしてかということです。

編集：

例：このコードが機能するのはなぜですか？

（このコミュニティWikiを参照）クロスオリジンリソースシェアリングを使用していますか？

ありがとう！

クライアントが API へのコールバックを行うために Web サイトに埋め込むことができる HTML のスニピットを提供しています。この HTML は単純なフォームであり、当社のサーバーでホストされている Javascript ファイルです。

これは、クライアントが Web サイト (clientsite.com) でホストするものです。

makeCallback が呼び出されると、mysite.com でホストされているスクリプトは次のことを行います。

スクリプトのドメインと XHR リクエストのドメインは同じですが、フォームとスクリプト タグをホストする HTML は clientsite.com にあることに注意してください。

これは FF と Chrome では問題なく動作しますが、IE ではアクセス拒否エラーが発生します。same-origin-policy と関係があると思いますが、これが FF と Chrome では機能するのに IE では機能しない理由を理解しようとしています。IEで動作させる方法はありますか？

ありがとう

多くの開発者と同様に、サーバー「A」が提供する JavaScript をサーバー「B」の Web サービスと通信させたいと考えていますが、現在の同一生成元ポリシーの実現が妨げられています。これを克服する最も安全な方法 (私が見つけたもの) は、サーバー "A" に配置され、サーバー "A" と "B" の間のプロキシとして機能するサーバー スクリプトです。しかし、この JavaScript をさまざまな顧客環境 (RoR、PHP、Python、.NET など) にデプロイしたいが、それらすべてのプロキシ スクリプトを作成できない場合は、どうすればよいでしょうか?

JSONP を使用してください、と言う人もいます。Doug Crockford は、彼の Web サイトとインタビューで、スクリプト タグ ハック (JSONP で使用される) は、同一生成元ポリシーを回避する安全でない方法であると指摘しました。「A」が提供するスクリプトが、「B」が本人であること、および返されるデータが悪意のあるものではないこと、またはそのページの機密ユーザー データ (クレジット カード番号など) をキャプチャすることを確認する方法はありません。卑劣な人々にそれを送信します。これは妥当な懸念のように思えますが、script タグ hack を単独で使用し、厳密に JSON で通信するとどうなるでしょうか? それは安全ですか？そうでない場合、なぜですか？HTTPS を使用すると、より安全になりますか? シナリオの例をいただければ幸いです。

補遺: IE6 のサポートが必要です。サードパーティのブラウザ拡張機能はオプションではありません。スクリプト タグのハッキングのメリットとリスクに対処することに固執しましょう。

Chrome拡張機能を作成していますが、指定されたURLをクリーンアップして、セキュリティの起源を取得できるようにしたいと考えています。location.hostを使用するとうまくいくようですが、常に使用できるとは限りません。たとえば、IFrame要素の発信元を取得したい場合、呼び出しはブロックされます。

WebKitのソースを見ると、これは簡単な作業とはほど遠いようです。JavaScript、C ++、またはChromeのAPIのいずれかを使用できます（WebKitのコードを使用すると、さらに大量のファイルがドラッグされるため、やり過ぎです）。

ウェブサイトhttp://www.mysite.comに外部jsファイルが追加されている場合

js ファイル内にはhttp://www.yoursite.com/new.js、スクリプトへの ajax 呼び出しがあります。http://www.yoursite.com/new.js

このような場合、別の Web サイトからサイト内のスクリプトを呼び出しているため、同じ生成元ポリシーのセキュリティ上の問題が発生するでしょうか?

この質問はスーパー ユーザーにも投稿しています。私の意見では、この質問は 2 つに重なっています... CouchDB の REST-ful インターフェース用 の単純な JavaScript ラッパー


を 作成していますが、同じオリジン ポリシーの問題で立ち往生しています。

これまでのところ、Mozilla FireFox でローカルに動作するようにコードを開発してきましたが、これは概念実証としてのみです。私のサーバーは、localhost、ポート 5984 で実行されています。

Mozilla FireFox でクロスオリジン ポリシーを無効にするには、PrivilegeManagerを使用できますが、サーバーに対して PUT リクエストを実行できないという意味では、中途半端なだけです...

サーバーの場所を非表示にするようにサーバーを構成して、同じ生成元ポリシーの問題を回避するためにブラウザー固有の回避策を実装する必要がないようにする方法はありますか? そうでない場合: 同一オリジン ポリシーを完全に無効にするブラウザの回避策はありますか?

同じドメイン上の2つの別々のサーバー間でリクエストを共有しているJavaScriptがあります。

.comはJavaScriptのドメインの要件ですか？

この場合、両方のサーバーは.abc.tyyドメイン上にあり、tyyは通常は.comになります。

ドメインに.comしか使用できないのではないかと思いますか？パーミッション拒否エラーが発生しますが、このコードは同じドメイン（.com）上の他の別々のサーバーで正常に機能します。

更新： これがまさに私がこれを使用している方法です：

123.abc.tyyには、アクセスしたいプロパティをロードするスクリプトがあります。

スクリプトタグを開いたときの123.abc.tyyのスクリプトは、document.domainを「abc.tyy」に設定します。

123.abc.tyyのスクリプトFROM234.abc.tyyで「getUser（）」関数を呼び出すと、アクセス許可が拒否されたというエラーが発生します。

「getUser（）」を呼び出す方法は次のとおりです。ブラウザでhttp://123.abc.tyyにアクセスすると、サイトでは、そのフレームの1つにロードするURLを指定できます。そのURLをそのページのhttp://234.abc.tyy/BeginLoadPatient.aspx "にポイントすると、次のようになります。

window.location =' http://234.abc.tyy/LoadPatient.aspx?PatientId= ' + getUser（）'; getUserは123.abc.tyyで作成された関数です

信頼できるサイトに234.abc.tyyと123.abc.tyyを追加すると、すべてが正常に機能します。これは、同一生成元ポリシーをスキップしますか？

SOP（Same Origin Policy）の本当の意味とは？

これは、あるオリジンの Javascript コードが別のオリジンのリソースにアクセスできないことを意味します。しかし、「リソース」という言葉は正確には何を意味するのでしょうか? 例えば：

1. Javascript コードは、別のサイトから IMAGES にアクセスできます。
2. Javascript コードは、別の側に ajax 要求を行うことはできません。

ただし、JSON パディングを使用すると、パディングされたスクリプト タグの読み込みが完了した後、サード パーティのスクリプトが指定されたコールバックを呼び出します。あるサイトの Javascript コードが、別のサイトの Javascript コードのメソッドを呼び出しています。これは SOP に違反しますか?

この質問は以前に質問され、正しく回答されましたが、解決策が投稿されていないようです。

サイトにiframeがあり、それらが別のドメインのフレームに囲まれないようにしたい場合、単純なフレームバスティングは役に立ちません。

ただし、他のドメインへのクロスフレームスクリプトは例外を生成するはずなので、次のようなものはiframe内でうまく機能するようです。

上記ifは、iframeのクロスドメインフレーミングを防ぐのに十分なはずです。false例外を返すかスローするだけでよいので、とにかくスクリプトがthrowブラウザのステートメントに到達する可能性はありますか？

これは、他のドメインからのフレーミングのみを防ぐのに十分でしょうか？

編集：同様の解決策がここで示唆されていますが、フレームバスティングコードを含めるために親フレームに依存することはありません。iframeがクロスドメインであるかどうかを検出し、それを無効にします。基本的に、「例外が発生した場合は、他のフレームにアクセスしてバストを試行する」と同じソリューションです。

SSL接続を介して動作するSmartGWTフレームワークを使用してアプリを開発しています。SmartGwt ライブラリは十分に大きく、https を使用するとキャッシュが防止されます。JSONP を使用して http 経由で SmartGwt アプリの静的コンテンツにアクセスする方法はありますか? または、この場合、静的コンテンツ キャッシュの他の方法を提案できますか?

ありがとう