問題タブ [same-origin-policy]

HTML DOM や Javascript の作成者がクロスドメイン リクエストを許可しないことにしたのはなぜですか?

許可しないことによる非常に小さなセキュリティ上の利点がいくつか見られますが、長い目で見れば、Javascript インジェクション攻撃の威力を弱めようとする試みのようです。いずれにせよ、JSONP ではすべて意味がありません。これは、javascript コードを作成するのが少し難しく、サーバー側の協力が必要であることを意味します (ただし、独自のサーバーである可能性があります)。

AJAX リクエストが同じドメインに限定されるのはなぜですか? この背後にある理由は何ですか？

外部の場所からのファイルのリクエストに問題は見られません。また、XMLHTTP リクエストを作成するサーバーは、外部の場所に問題なく取得および投稿しているようです。

私は jQuery を扱う初心者プログラマーで、誰か助けてくれるかどうか疑問に思っています。

基本的に、記事のソーシャル ボタンのセクション用にいくつかの html を作成しました。

jQuery の .load() 関数を使用してすべての記事に取り込むことを目的として、これをアップロードしました。

IE7 では動作しますが、Firefox や Chrome では動作しません。誰かがそれを修正するのを助けることができますか?

クロスドメイン iframe では contentWindow プロパティにアクセスできないため、純粋な Firefox では機能します。この問題を分離するコードの束を次に示します。

1. ローカル サーバーに 3 つのファイルを作成します。

test.html

iframe.html

postmsg.js

この js ファイルは、標準のインクルード ファイル html として機能し、最初のコメントは無視されますが、拡張子を user.js に変更すると、グリースモンキーにインストールでき、contentWindow が呼び出されると次の行で機能しなくなります。

メインとフレーム化されたhtmlがjsインタープリターの同じサーバー上にある場合でも、jsインタープリターはlocalhostと127.0.0.1が同一であることを認識しないため、これらのファイルは異なるドメインにあることに注意してください

「@include *」を入れたので、別の Web サイトで確認できます。このエラーは、クロス ドメインの iframe にのみ存在するようです。translate.google.com にアクセスすると、複数の iframe があり、すべてが同じドメインにある場合、このスクリプトは期待どおりに機能します。

問題は、グリースモンキーでクロスドメインセキュリティチェックが何をしているのかということです。これは、このツールの使用法と矛盾します。悪意のある Web サイトはスクリプトをインストールできません。ユーザーはそれに同意する必要があります。クロスドメインiframeに表示されているプロパティが実際にはブラウザのjsエンジンで利用できないことをfirebugが示していなかったため、私はこれに長い間行き詰まりました。

ユーザーが外部のWebサイトにアクセスできるサービスを作成したいと思います。その後、返されたソースは、アプリケーションによって（目的を問わず）変更され、ユーザーに返されます。

通常、サーバーを介してすべてのトラフィックをリダイレクトするため、サーバーが外部ソースにアクセスします。これは、外部ソースに必要なポリシーファイルがない限り、HTML5およびフラッシュソケットが外部ソースにアクセスできないためです（これがfalseの場合は修正してください）。ユーザーがクライアントにアクセスを希望している場合でも、外部ソース自体にそのようなポリシーファイルがない場合は、これらの外部ソースにアクセスできません。

私の質問は、Javaアプレットは、ポリシーファイルに関係なく、ユーザーが許可した場合、外部ソースにアクセスできるかどうかです。これは通常どのように行われますか？

そうでない場合、他に試すことができるものはありますか？1.無料サービスのために帯域幅とサーバーリソースを頻繁に使用し、2。サーバーがスパムボットまたは帯域幅ホガーとしてマークされる可能性が高いため、サーバーを介してすべてのトラフィックをリダイレクトすることはできません。

前もって感謝します。

よろしく、トム

ローカルIISでWCFSOAP（C＃）ベースのWebサービスを実行していて、ASP.net Webサイトを作成し、ローカルIISで再度実行している場合、WebページからHTTP要求呼び出しを行うjavascriptは成功しますか？それとも、同一生成元ポリシーのルールがここで機能しますか？

Google Data Protocol の JavaScript クライアント ライブラリについて読んだことがありますが、適切なインターフェース (Docs、Spreadsheets、Calendar など) を持つ任意の Google サービスにアクセスできるようです。

自分のドメインでホストされている自分のアプリケーションでこのクライアントを使用する場合、js クライアント ライブラリは、違反していると思われる同一オリジン ポリシーをどのように回避しますか? これが機能するのは、クライアント ライブラリ コード自体が Google のトップ レベル ドメインでホストされているためですか?

ajax、getJSON、およびそのような関数を使用して、ローカル (非サーバー) 開発用コンピューターから外部 URL を取得しようとしています。サーバーにアップロードする代わりに、ローカルでテストできるように、同じオリジン ポリシーをバイパスする方法はありますか?

sample.xml1 つの Web サーバーにあるファイルがあります。別のサーバーで実行されている GWT アプリケーションからこのファイルにアクセスしたいと考えています。GWTアプリケーションを提供する同じサーバーにRPC呼び出しを行い、サーバー側で必要なファイルにアクセスしたくありません(プロキシなど)。アプリケーションは Web サーバーで静的ファイルとしてホストされるため、クライアント側からファイルに直接アクセスしたいと考えています。

それを行う方法はありますか？

私は過去 5 か月間 gwt アプリの開発に費やしてきましたが、今はサード パーティの人々がそれを使い始める時です。これに備えて、そのうちの 1 人が私のアプリをリバース プロキシの背後にセットアップしましたが、これはすぐにブラウザーの同一オリジン ポリシーの問題を引き起こしました。応答ヘッダーに問題があると思いますが、問題を解決するためにそれらを書き直すことはできません。私はこれを試しました

私が望む振る舞いを模倣するある種の素朴な試みで。うまくいきませんでした（誰も驚かないことに）。

これについて何か知っている人なら誰でも、これを読むとニヤリと首を横に振るでしょうが、私は彼らを責めません。私だったら、私もニヤリと笑うでしょう... 私はこれについて何も知らないので、当然、この問題を解決するのは非常に困難です. どんな助けでも大歓迎です。

ヘッダーの書き換えを機能させて、対処している SOP の問題を回避するにはどうすればよいですか?

編集：私が得ている正確な問題は、次のようなポップアップです：

「SmartClient は URL ' https://localhost/app/resource?action= 'doStuffs'' に直接接続できません」は、ブラウザの同一オリジン ポリシーによるものです。この問題を回避するには、ホストとポート番号 (たとえ localhost の場合でも) を削除するか、XJSONDataSource プロトコル (クロスサイト呼び出しを可能にする) を使用するか、SmartClient サーバーに含まれるサーバー側の HttpProxy を使用してください。」

しかし、サーバーの上にプロキシがあるので、スマートクライアントの HttpProxy は必要ありません。これがシリアル化の問題である可能性があるという兆候は得られませんでしたが、おそらくこのメッセージは本当の問題を隠しています...

解決策 chris_l と saret の両方が解決策を見つけるのに役立ちましたが、マークできるのは 1 つだけなので、chris_l からの回答にマークを付けました。読者の皆さんは、ぜひ両方とも取り上げていただきたいと思います。解決策は非常に簡単で、サーバーへの絶対パスを削除し、相対パスのみを使用するだけでうまくいきました。みんなありがとう！