10

ホームページに、XHRPOSTを介してURLhttps://mydomain.com/send_smsに送信するように設定されたフォームがあります。

Internet Explorer（http://mydomain.com）で非SSLバージョンのホームページにアクセスしてフォームを送信しても、何も起こりません。Webkitコンソールで、次のような役立つエラーが表示されますOrigin http://mydomain.com is not allowed by Access-Control-Allow-Origin.

200 OKただし、Firefox 13では、応答の本文は空白ですが、要求は明確に送信され、aはを返します。さらに、サーバー側のアクション（SMSの送信）は、実際にはFirefoxの要求によってトリガーされますが、他のブラウザーによってはトリガーされません。

同一生成元ポリシーはリクエストの送信も拒否するといつも思っていましたが、許可されていないのはブラウザがレスポンスからデータを受信して​​いるのではないでしょうか。

これがMozillaによる実装の意図的な違い（またはおそらく見落とし）であるかどうかを誰かが知っていますか？

4

2 に答える 2

2

まず第一に、http://example.comそしてhttps://example.com異なる起源です。XHRレベル1の場合、これはクロスオリジンリクエストが許可されないことを意味します。

ただし、 CORSがサポートされている場合（サーバーとクライアントの両方で！）にクロスオリジンリクエストをサポートする現在のXHR（レベル2）の場合、クロスオリジンリクエストは次のいずれかになります。

  • 単純なクロス組織リクエスト（

    • リクエストメソッドは、、、GETまたはHEAD、POSTであり、
    • リクエストヘッダーフィールドはいずれも、、、、、または、および以外のものではありませAcceptんAccept-LanguageContent-LanguageContent-Type
    • プリフライトフラグが設定されていません

    また

  • プリフライトを必要とするクロスオリジンリクエスト、それ以外の場合。

単純なクロスオリジンリクエストの場合、ブラウザはリクエストを送信できます。ただし、応答を受信すると、サーバーがリソースの共有を許可しているかどうかを確認する必要があります。ここで、Access-Control-Allow-Originヘッダーフィールドとその他のAccess-Control-*応答ヘッダーフィールドがチェックされます。そして、このチェックに合格した場合にのみ、ブラウザはスクリプトが応答を読み取ることを許可します。

他のクロスオリジンリクエストの場合、実際のリクエストで送信できる情報をサーバーとネゴシエートするためにプリフライトが必要です。このプリフライトリクエストは、基本的にOPTIONS、実際のリクエストに含まれるもの（リクエストメソッドとヘッダーフィールド）をサーバーに通知するリクエストです。次に、サーバーはそのような要求を許可するかどうかを決定できます。

あなたの場合、観察された行動には複数の理由が考えられます。send_smsスクリプトは、CORSのサーバー側の部分をサポートしていないと思います。

于 2012-06-11T20:35:04.937 に答える
0

データの送信は、受信と同じように禁止する必要があります。たとえば、このページに悪意のあるJSがあり、各キーストロークをランダムなサーバーに送信していた場合はどうなりますか？この場合、送信は受信よりも悪質です（余談ですが、これは、同じオリジンポリシーの対象ではないため、クエリ文字列を使用して画像やスクリプトなどのリソースを要求することで実際に実現できます）。

私は過去にわずかな違いに遭遇しましたが、それは通常、レガシーIEで発生しました。

私にとって、Firefoxの不一致はバグです（バニラインストールを提供することにはこの特性があります）。異なるプロトコル（HTTPとHTTPS）は異なるオリジンと同等であり、同じプロトコル上のサブドメインでさえ異なるオリジンであると見なされるため、FF13は間違いなくAJAX要求を行うべきではありません。

CORS（Cross-Origin Resource Sharing）が設定されていない場合、FF13はそれをサポートするためにテストした唯一のブラウザーですか？

于 2012-06-11T19:05:10.097 に答える