「Cross Origin Resource Sharing (CORS)」の版間の差分

(同じ利用者による、間の1版が非表示)

13行目:

ユーザーがhttp://www.example.com、ページがhttp://service.example.com からデータをフェッチするためにクロスオリジン・リクエストを試みたとする。CORS対応ブラウザは、以下のようにservice.example.comへのクロスオリジン・リクエストを試みる。

# ブラウザは、親ページを提供したドメインを含むservice.example.comへの余分なOrigin HTTPヘッダーを持つGETリクエストを送信します： <br />

# ブラウザは、親ページを提供したドメインを含むservice.example.comへの余分なOrigin HTTPヘッダーを持つGETリクエストを送信します： <pre><nowiki>Origin: http://www.example.com</nowiki></pre>

#

# service.example.comのサーバーは、これら3つのレスポンスのいずれかを送信する：

#* リクエストされたデータは、オリジンからのリクエストが許可されていることを示す応答中の<code>Access-Control-Allow-Origin</code> (ACAO)ヘッダーとともに送られる。例えば、この場合はこうなる：<pre><nowiki>Access-Control-Allow-Origin: http://www.example.com</nowiki></pre>

#* リクエストされたデータは、<code>Access-Control-Allow-Origin</code> (ACAO)ヘッダーと共に、すべてのドメインからのリクエストが許可されることを示すワイルドカードを持つ： <pre><nowiki>Access-Control-Allow-Origin: *</nowiki></pre>

#* サーバーがクロスオリジン・リクエストを許可しない場合のエラー・ページ。

ワイルドカードの同一生成元ポリシーは、ページやAPIのレスポンスが、どのサイトのどのコードからもアクセスできることを意図している場合に適切です。Google Fontsのようなパブリック・ホスティング・サービスで自由に利用できるウェブ・フォントがその例です。

ワイルドカードの同一オリジン・ポリシーは、ページが推測不可能なURLを持ち、秘密を知っている人なら誰でもアクセスできることを意味する、オブジェクト・キャパビリティ・モデルでも広く適切に使用されている。

つまり、HTTP認証、クライアント側SSL証明書、クッキーをクロスドメインリクエストで送ることを許可しない。

CORSアーキテクチャでは、Access-Control-Allow-Originヘッダーは、元のWebアプリケーションサーバー（www.example.com）ではなく、外部のWebサービス（service.example.com）によって設定されることに注意してください。ここで、service.example.comはCORSを使用して、ブラウザがwww.example.com、service.example.comへのリクエストを許可する。

サイトがヘッダ "Access-Control-Allow-Credentials:true "を指定すると、サードパーティのサイトが特権的なアクションを実行し、機密情報を取得できる可能性があります。

@@ 13行目: / 13行目: @@
 ユーザーがhttp://www.example.com、ページがhttp://service.example.com からデータをフェッチするためにクロスオリジン・リクエストを試みたとする。CORS対応ブラウザは、以下のようにservice.example.comへのクロスオリジン・リクエストを試みる。
-# ブラウザは、親ページを提供したドメインを含むservice.example.comへの余分なOrigin HTTPヘッダーを持つGETリクエストを送信します： <br />
+# ブラウザは、親ページを提供したドメインを含むservice.example.comへの余分なOrigin HTTPヘッダーを持つGETリクエストを送信します： <pre><nowiki>Origin: http://www.example.com</nowiki></pre>
-#
+# service.example.comのサーバーは、これら3つのレスポンスのいずれかを送信する：
+#* リクエストされたデータは、オリジンからのリクエストが許可されてい ることを示す応答中の<code>Access-Control-Allow-Origin</code> (ACAO)ヘッダーとともに送られる。例えば、この場合はこうなる：<pre><nowiki>Access-Control-Allow-Origin: http://www.example.com</nowiki></pre>
+#* リクエストされたデータは、<code>Access-Control-Allow-Origin</code> (ACAO)ヘッダーと 共に、すべてのドメインからのリクエストが許可されることを示す ワイルドカードを持つ： <pre><nowiki>Access-Control-Allow-Origin: *</nowiki></pre>
+#* サーバーがクロスオリジン・リクエストを許可しない場合のエラー・ページ。
+ワイルドカードの同一生成元ポリシーは、ページやAPIのレスポンスが、どのサイトのどのコードからもアクセスできることを意図している場合に適切です。Google Fontsのようなパブリック・ホスティング・サービスで自由に利用できるウェブ・フォントがその例です。
+ワイルドカードの同一オリジン・ポリシーは、ページが推測不可能なURLを持ち、秘密を知っている人なら誰でもアクセスできることを意味する、オブジェクト・キャパビリティ・モデルでも広く適切に使用されている。
+つまり、HTTP認証、クライアント側SSL証明書、クッキーをクロスドメインリクエストで送ることを許可しない。
+CORSアーキテクチャでは、Access-Control-Allow-Originヘッダーは、元のWebアプリケーションサーバー（www.example.com）ではなく、外部のWebサービス（service.example.com）によって設定されることに注意してください。ここで、service.example.comはCORSを使用して、ブラウザがwww.example.com、service.example.comへのリクエストを許可する。
+サイトがヘッダ "Access-Control-Allow-Credentials:true "を指定すると、サードパーティのサイトが特権的なアクションを実行し、機密情報を取得できる可能性があります。