CORS, 同一オリジンポリシーについてまとめる

3.4.2. ネットワークアクセス
ネットワークリソースへのアクセスの可否は、［ そのリソースは、アクセスを試みている内容と同じ生成元に属しているかどうか ］に依存する。
一般に、別の生成元から情報を読み取ることは禁止される。 しかしながら，一部の種類のリソースを利用することは、他の生成元から検索取得する場合でも許可される。 例えば生成元には、どの生成元からの［ スクリプトを実行する／画像を描画する／スタイルシートを適用する ］ことも許可されている 【この文書が書かれた頃までは — 現在はもっと制約されている】 。 同様に生成元は、 HTML のフレーム内の HTML 文書など，別の生成元からの内容を表示できる。 ネットワークリソースには、他の生成元に自身の情報を読み取らせるオプトインを備えるものもある — 例えば Cross-Origin Resource Sharing [CORS] を利用して。 これらの事例でアクセスが是認されるかどうかは、概して生成元ごとに基づく。

https://triple-underscore.github.io/RFC6454-ja.html#section-3.2

なるほど、一般的に、あるオリジンのリソースから、別のオリジンのリソースにアクセスすることは禁止されているのか。

https://datatracker.ietf.org/doc/html/rfc6454#section-3.2

"オリジン"という概念は、ウェブのセキュリティとプライバシーの向上を目的として生まれました。

ウェブブラウザは、ウェブページを表示する際にそのページが所属するドメインを識別します。この識別子は通常、URL（Uniform Resource Locator）の一部で、例えば "https://www.example.com/page.html" といった形で表されます。

しかし、ウェブ上には様々なドメインが存在し、それぞれ異なるサービスやコンテンツを提供しています。セキュリティの観点から、あるドメインで読み込んだコンテンツが他のドメインのコンテンツに影響を与えたり、情報を取得したりすることを制限する必要がありました。

この制限を実現するために、"Same-Origin Policy（同一オリジンポリシー）"が導入されました。同一オリジンポリシーは、異なるオリジン（異なるドメイン、プロトコル、ポート）からのリソースへのアクセスを制限し、セキュリティを強化します。

例えば、ウェブページが "https://www.example.com" というオリジンから読み込まれた場合、そのページは通常 "https://www.example.com/page.html" や "https://www.example.com/image.jpg" などのリソースにはアクセスできますが、他のオリジン（例えば "https://www.differentdomain.com"）のリソースにはアクセスできません。

このようにして、オリジンの概念はウェブセキュリティを強化し、クロスサイトスクリプティング（XSS）やクロスサイトリクエストフォージェリ（CSRF）などのセキュリティ攻撃からウェブアプリケーションを保護する重要な仕組みとなっています。

オリジンは、tcpでIPアドレス以外にポート番号まで指定して、アプリケーションを特定するのに似ている
オリジンの場合は、プロトコルも関わっているけど。

あるオリジンのリソースから異なるオリジンのリソースにアクセスする際は、ブラウザが勝手に制御してくれるそう。

https://ja.wikipedia.org/wiki/同一生成元ポリシー

あるオリジンによって読み込まれた文書やスクリプトっていうのが大事。
これはUAからリクエストする際の話。

CORSプロトコルは、応答をクロスオリジンで共有できるかどうかを示す一連のヘッダーで構成される。

For requests that are more involved than what is possible with HTML’s form element, a CORS-preflight request is performed, to ensure request’s current URL supports the CORS protocol.

CORSプリフライトリクエストは、実際のリクエストの前に行われる追加のリクエストであり、リクエストの送信前にサーバーがリクエストを受け入れるかどうかを確認します。これは主に、複雑なリクエスト（例えば、一部の特殊なHTTPメソッドを使用したり、カスタムヘッダーを含めたりする場合）の場合に行われます。

CORSプリフライトリクエストは、リクエストを送信するページの現在のURLがCORSプロトコルをサポートしているかどうかを確認します。もしサポートされていない場合、リクエストは拒否される可能性があります。

簡単に言うと、この文は、HTMLのフォーム要素だけでは処理できない複雑なリクエストがある場合に、そのリクエストがCORSプロトコルを遵守しているかを確認するために、CORSプリフライトリクエストが行われると説明しています

CORSにおけるHTTPリクエスト

CORSリクエストは Origin ヘッダーを含むHTTPリクエストである。メソッドが GET でも HEAD でもないすべてのリクエストにも Origin ヘッダーが含まれるので、CORS プロトコルに参加していることを確実に識別することはできない。

CORS-preflightリクエストは、CORSプロトコルが理解されているかどうかを確認するCORSリクエストである。メソッドとして OPTIONS を使用し、これらのヘッダを含む：

アクセス制御リクエストメソッド`（Access-Control-Request-Method
同じリソースに対する将来のCORSリクエストがどのメソッドを使用するかを示す。

アクセス制御リクエストヘッダ Access-Control-Request-Headers`
同じリソースに対する将来の CORS リクエストが使用する可能性のあるヘッダを示す。

3.2.3.HTTP応答
CORSリクエストに対するHTTPレスポンスには、以下のヘッダを含めることができます：

Access-Control-Allow-Origin。 レスポンスに Origin リクエストヘッダのリテラル値 (nullとすることもできる) または*` を返すことで、レスポンスを共有できるかどうかを示す。

アクセス制御許可認証 (Access-Control-Allow-Credentials`)
リクエストのクレデンシャルモードが "include" の場合に、レスポンスを共有できるかどうかを示す。

CORS-preflightリクエストでは、リクエストの認証情報モードは常に "same-origin"、つまり認証情報を除外するが、それ以降のCORSリクエストでは除外されないかもしれない。したがって、CORS-preflightリクエストに対するHTTPレスポンスの一部として、サポートを示す必要がある。

CORS-preflight要求に対するHTTP応答には、以下のヘッダを含めることができる：

Access-Control-Allow-Methods`。
CORSプロトコルの目的のために、応答のURLでサポートされているメソッドを示します。

アクセス制御許可ヘッダ(Access-Control-Allow-Headers`)
CORSプロトコルの目的のために、どのヘッダがレスポンスのURLでサポートされているかを示す。

Access-Control-Max-Age (アクセス制御の最大年齢)
Access-Control-Allow-MethodsヘッダとAccess-Control-Allow-Headers` ヘッダが提供する情報をキャッシュできる秒数 (デフォルトは 5 秒) を示す。

CORS-preflightリクエストではないCORSリクエストに対するHTTPレスポンスには、以下のヘッダを含めることもできる：

Access-Control-Expose-Headersヘッダー。 Access-Control-Expose-Headers どのヘッダをレスポンスの一部として公開できるかを、ヘッダ名のリストで示します。

成功した HTTP レスポンス、つまりサーバー開発者が共有することを意図した CORS リクエストに対するレスポンスは、リクエストと一致する値を持つ上記のヘッダーを含む限り、どのようなステータスでも使用できます。

CORS-プリフライトリクエストに対する成功したHTTPレスポンスは、200または204などのokステータスに制限される以外は同様である。

それ以外のHTTPレスポンスは成功ではなく、共有されずに終わるか、CORS-preflightリクエストに失敗します。それにもかかわらず、サーバーが実行する作業は、タイミングなどのサイドチャネルを通じて漏れる可能性があることに注意してください。サーバー開発者がこのことを明示的に示したい場合は、関連するヘッダーの省略と組み合わせて403ステータスを使用できます。

必要であれば、"failure" も共有できますが、それは HTTP レスポンスの成功になります。そのため、CORS-preflightリクエストでないCORSリクエストに対するHTTPレスポンスが成功した場合、ステータスは403を含むあらゆるものになり得る。

最終的にサーバー開発者は、HTTP レスポンスをどのように処理するかについて多くの自由を持っており、これらの戦術は、CORS-preflight 要求に対するレスポンスとそれに続く CORS 要求とで異なる可能性がある：

静的レスポンスを提供することができます。これは、キャッシュ仲介業者と連携する際に役立ちます。静的レスポンスは、CORSリクエストによって成功することも成功しないこともある。これは問題ない。

CORSリクエストに調整された動的レスポンスを提供できる。これは、レスポンスボディを特定のオリジンに合わせる必要がある場合や、レスポンスが認証情報を持ち、一連のオリジンに対して成功する必要がある場合に役立ちます。

https://fetch.spec.whatwg.org/#http-cors-protocol

CORS は様々なエラーで失敗することがありますが、セキュリティ上の理由から、エラーについて JavaScript から知ることができないよう定められています

フロントエンド側からフォームでpostリクエストする際に、Originヘッダーを勝手に送っていることを確認できた。
サーバーサイドからAccess-Control-Allow-Originヘッダーが送られてこなかったが、なぜか画面に他のオリジンのソースが表示できた。フォームだからかな？

<!-- same_origin_policy.html -->
<!-- localhost:8080が送ってくるフォーム -->
<html>
<body>
  <h1>ユーザー検索</h1>
  <!-- methodをgetにしちゃうと、ボディがクエリパラメータになっちゃうね。サーチくらいならまだ良いか。-->
  <!-- 自作サーバーにクエリストリングの処理を入れてないから、postにした。サーチは本来ならgetが良い。-->
  <form action="http://localhost:3030/api/users/search" method="post">
    email: <input name="email" type="email"/> <br>
    <input name="submit_name" type="submit" value="送信">
  </form>
</body>
</html>

てかフォームだと受け取ったレスポンスをブラウザに表示しちゃうから、リソースをシェアしているってよりかはそのリソースをブラウザが受け取って、元々のオリジンを無視して表示しちゃったって感じだね。

jsでリクエストしてみた

<!-- same_origin_policy.html -->
<!-- localhost:8080が送ってくるフォーム -->
<html>
<body>
  <h1>ユーザー検索</h1>
  <!-- methodをgetにしちゃうと、ボディがクエリパラメータになっちゃうね。サーチくらいならまだ良いか。-->
  <!-- 自作サーバーにクエリストリングの処理を入れてないから、postにした。サーチは本来ならgetが良い。-->
  <button id="button">検索</button>
  <script>
    document.getElementById("button").addEventListener("click",() => {
      const request = new XMLHttpRequest();
      // onreadystatechangeプロパティは、XMLHttpRequestオブジェクトの状態が変化するたびに実行される関数を指定します：
      request.onreadystatechange = () => {
        // readyStateプロパティが4で、statusプロパティが200のとき、応答はreadyである：
        if (this.readyState == 4 && this.state == 200) {
          alert(request.responseText);
        }
      }
      request.open("GET", "http://localhost:3030/api/users/search", true);
      request.send();
    })
  </script>
</body>
</html>

確かに検索ボタンを押して、jsからHTTPリクエストを発火させようとしたら、Same-Origin-Policyのエラーが出た。要はhttp://localhost:8080のオリジンから、http://localhost:3030のオリジンにアクセスしようとしたから、オリジン違くねとブラウザがこのエラーを出した。
フォームだとSame-Origin-Policyの制約がないのかもね。

オリジン 'http://localhost:8080' から 'http://localhost:3030/api/users/search' の XMLHttpRequest へのアクセスは、CORS ポリシーによってブロックされました： 要求されたリソースに 'Access-Control-Allow-Origin' ヘッダーがありません。

https://zenn.dev/qnighy/articles/6ff23c47018380

jsリクエストのリクエストヘッダーを見ると、ちゃんとOriginヘッダーを送っているのが確認できる。
Originヘッダは異なるオリジンにリクエストを出す際に自動でブラウザがつけてくれるヘッダ。 Originヘッダには、リクエスト元のオリジンが指定されている

コントローラにこのオリジンならリソースの使用を許可するよというヘッダー(Access-Control-Allow-Origin)を追加した

	// コルスの設定
	response.SetHeader("Access-Control-Allow-Origin", "http://localhost:8080")

htmlもコード変更した。

<html>
<body>
  <h1>ユーザー検索</h1>
  <!-- methodをgetにしちゃうと、ボディがクエリパラメータになっちゃうね。サーチくらいならまだ良いか。-->
  <!-- 自作サーバーにクエリストリングの処理を入れてないから、postにした。サーチは本来ならgetが良い。-->
  <button id="button">検索</button>
  <script>
    document.getElementById("button").addEventListener("click",() => {
      const request = new XMLHttpRequest();
      // onreadystatechangeプロパティは、XMLHttpRequestオブジェクトの状態が変化するたびに実行される関数を指定します：
      request.onreadystatechange = () => {
        // readyStateプロパティが4で、statusプロパティが200のとき、応答はreadyである：
        if (request.readyState == 4 && request.status == 200) {
          alert(request.responseText);
        }
      }
      request.open("GET", "http://localhost:3030/api/users/search", true);
      request.send();
    })
  </script>
</body>
</html>

できた。
リクエストヘッダーにOrigin。レスポンスヘッダにAccess-Control-Allow-Originヘッダがあることが確認できた。

jsのXMLHTTPリクエストで取得したリソースもちゃんと利用できた。

CORSにおけるシンプルリクエストとは

別オリジンへのリクエストによっては、プリフライトリクエストを発生しません。この時のリクエストをシンプルリクエストという。このシンプルリクエストは、以下の条件を全て満たす。これらはHTMLフォームから送られるリクエストを基準としている。
(HTMLフォームはもともと異なるオリジンに対してリクエストを無条件に送信できる。そのため、HTMLフォームで送れる程度に制限しておけば、XMLHttpRequestでクロスオリジンにリクエストを送信しても、リスクはそれほど変わらないと考えれている。ただしCSRFのリスクとかはあるけど。サーバー側でCSRFの対策をする)

シンプルリクエストの条件

メソッドは下記のうちいずれか

• GET
• HEAD
• POST

ユーザーエージェント(Webの場合はブラウザ)によって自動的に設定されたヘッダー (たとえば Connection、 User-Agent、 または Fetch 仕様書で禁止ヘッダー名として定義されているヘッダー)を除いて、手動で設定できるヘッダーは、 Fetch 仕様書で CORS セーフリストリクエストヘッダーとして定義されている以下のヘッダーだけである

• Accept
• Accept-Language
• Content-Language
• Content-Type(以下しか指定できない)
  • application/x-www-form-urlencoded
  • multipart/form-data
  • text/plain
• Range
• リクエストに ReadableStream オブジェクトが使用されていないこと。

プリフライリクエスト

CORS のプリフライトリクエストは CORS のリクエストの一つであり、サーバーが CORS プロトコルを理解していて準備がされていることを、特定のメソッドとヘッダーを使用してチェックします。

これは OPTIONS リクエストであり、 Access-Control-Request-Method,Access-Control-Request-Headers, Origin の 3 つの HTTP リクエストヘッダー使用します。

プリフライトリクエストはブラウザーが自動的に発行するものであり、通常は、フロントエンドの開発者が自分でそのようなリクエストを作成する必要はありません。これはリクエストが"to be preflighted"と修飾されている場合に現れ、単純リクエストの場合は省略されます。

プリフライトリクエストとは、サーバーがCORSプロトコルを理解して準備がされていることをチェックするためのリクエスト。クロスオリジンアクセスにおいて、「シンプルリクエストの条件」を満たさない場合に、プリフライトリクエストと呼ばれるHTTPリクエストが送信される。プリフライトリクエストは、ブラウザが自動的に発行するもの。別オリジンにし対してシンプルリクエストができる場合、プリフライトリクエストは発生しない。

プリフライトリクエストがOKだったら、別オリジンにリクエストを出してレスポンスを利用できる。

preflightは「飛行前に起こる」っていう意味の形容詞
https://eow.alc.co.jp/search?q=preflight

OPTIONS

HTTP の OPTIONSメソッドは、指定された URL またはサーバーの許可されている通信オプションをリクエストします。クライアントはこのメソッドで URL か、サーバー全体を表すアスタリスク (*) を指定することができます。

HTTPメソッドの一つ。指定されたURLまたはサーバーの許可されている通信オプションをリクエストする際に使うメソッド。
https://developer.mozilla.org/ja/docs/Web/HTTP/Methods/OPTIONS

Content-Type: application/jsonでリクエストすれば、プリフライトリクエストが発生するな。
プリフライトリクエストは、XHRでリクエストしようとしているリソースに対して、OPTIONSメソッドでリクエストが実行されていた。このプリフライトリクエストの実行結果でCORSに関するヘッダーを返していないと、プリフライトリクエストは成功しても、XHRでのリクエストが失敗する。

↓ プリフライトリクエストが実際に出されている図

↓ コンソールにもちゃんとエラーが出ている

エラーの内容を見てみる

Access to XMLHttpRequest at 'http://localhost:3030/api/users/search-after-preflight' from origin 'http://localhost:8080' has been blocked by CORS policy: Request header field content-type is not allowed by Access-Control-Allow-Headers in preflight response.

オリジン 'http://localhost:8080' から 'http://localhost:3030/api/users/search-after-preflight' の XMLHttpRequest へのアクセスは、CORS ポリシーによってブロックされました： リクエストヘッダーフィールド content-type は、プリフライト応答の Access-Control-Allow-Headers によって許可されていません

なるほど、つまり、プリフライトリクエストのヘッダーでcontent-Type: application/jsonが許可されていないから、プリフライトリクエスト後のリソースを取得するリクエストが失敗している。
(要はプリフライトリクエストのレスポンスでcontet-Type: application/jsonの使用を許可するヘッダが存在しないからこのエラーが出ている)

どうやって、プリフライトリクエストを許可するか。
プリフライトリクエストでどんなHTTPリクエストメッセージが飛んでいるのか見てみよう。

OPTIONS /api/users/search-after-preflight HTTP/1.1
# Host リクエストヘッダーは、リクエストが送信される先のサーバーのホスト名とポート番号を指定します。
Host: localhost:3030
Connection: keep-alive
# HTTP の Accept リクエストヘッダーは、クライアントが理解できるコンテンツタイプを MIME タイプで伝えます。 
Accept: */*
Access-Control-Request-Method: GET
Access-Control-Request-Headers: content-type
Origin: http://localhost:8080
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
Sec-Fetch-Dest: empty
Referer: http://localhost:8080/
Accept-Encoding: gzip, deflate, br
Accept-Language: ja-JP,ja;q=0.9,en-US;q=0.8,en;q=0.7,zh-CN;q=0.6,zh;q=0.5

https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Accept

プリフライトリクエストのこの3つのヘッダが特徴的。

# 同じリソースに対する今後の CORSリクエストに利用され得る 【リクエスト側が希望する】 メソッドを指示する。
Access-Control-Request-Method: GET
# 同じリソースに対する今後の CORS リクエストに利用され得る 【リクエスト側が希望する】 ヘッダを指示する。
Access-Control-Request-Headers: content-type
Origin: http://localhost:8080

このヘッダのリクエストに対してレスポンスでは以下のヘッダを応答する必要がある。

Access-Control-Allow-Methods
Access-Control-Allow-Headers
Access-Control-Allow-Origin

プリフライトリクエストのレスポンスを生成する際にヘッダーを追加したらいけた。
(下でAccess-Control-Allow-Originも追加している)

		response.SetHeader("Access-Control-Allow-Methods", "GET")
		response.SetHeader("Access-Control-Allow-Headers", "Content-Type")

プリフライトリクエストのレスポンス。レスポンスヘッダーでちゃんとこのリソースに対してGETメソッドとContent-Typeの使用を許可している。

プリフライトリクエストのレスポンスが帰ってきて、次のリクエストをしている。

ちゃんと動いている。

セッションカウンタのページを作ってみるか。

localhost:8080のhtmlはこんな感じ

<html>
<body>
  <h1>セッションカウンタ</h1>
  <span id="counter"></span>
  <!-- methodをgetにしちゃうと、ボディがクエリパラメータになっちゃうね。サーチくらいならまだ良いか。-->
  <!-- 自作サーバーにクエリストリングの処理を入れてないから、postにした。サーチは本来ならgetが良い。-->
  <button id="button">count up</button>
  <script>
    document.getElementById("button").addEventListener("click",() => {
      const request = new XMLHttpRequest();
      // onreadystatechangeプロパティは、XMLHttpRequestオブジェクトの状態が変化するたびに実行される関数を指定します：
      request.onreadystatechange = () => {
        // readyStateプロパティが4で、statusプロパティが200のとき、応答はreadyである：
        if (request.readyState == 4 && request.status == 200) {
          const span = document.getElementById("counter")
          span.textContent = request.responseText
        }
      }
      request.open("GET", "http://localhost:3030/api/authentication-included-request", true);
      request.send();
    })
  </script>
</body>
</html>

localhost:3030のサーバーサイドはこんな感じ

func (c *AuthenticationIncludedRequest) Action(request *http.Request) *http.Response {
	cookieHeaders := map[string]string{}
	cookie, isThere := request.Cookies["counter"]
	var response *http.Response

	if isThere {
		currentCount, _ := strconv.Atoi(cookie.Value)
		currentCount += 1
		cookieHeaders["counter"] = fmt.Sprintf("%v", currentCount)

		response = http.NewResponse(
			http.VersionsFor11,
			http.StatusSuccessCode,
			http.StatusReasonOk,
			request.TargetPath,
			[]byte{byte(currentCount)},
		)
	} else {
		currentCount := 1
		cookieHeaders["counter"] = fmt.Sprintf("%v", currentCount)

		response = http.NewResponse(
			http.VersionsFor11,
			http.StatusSuccessCode,
			http.StatusReasonOk,
			request.TargetPath,
			[]byte{byte(currentCount)},
		)
	}

	// クッキーの設定
	for key, value := range cookieHeaders {
		response.SetCookieHeader(fmt.Sprintf("%s=%s", key, value))
	}

	// コルスの設定
	response.SetHeader("Access-Control-Allow-Origin", "http://localhost:8080")

	return response
}

ボタンを押して、CORSリクエストが送信された。
CORSリクエストのレスポンスでSet-Cookieヘッダが入っているのは確認できた。しかし、ブラウザにクッキーが保存されない。そのせいで2回目にボタンを押した時のリクエストでクッキーが勝手に送信されないし。カウンターはずっと1のまま。

これを解決するには、XMLHTTPRequestのwithCredentialsプロパティにtrueをセットする必要がある。

とりあえずセットしてみた。

      request.open("GET", "http://localhost:3030/api/authentication-included-request", true);
      request.withCredentials = true;
      request.send();

リクエストのボタン押したら案の定エラーが出た

authentication-included-request:1 Access to XMLHttpRequest at 'http://localhost:3030/api/authentication-included-request' from origin 'http://localhost:8080' has been blocked by CORS policy: The value of the 'Access-Control-Allow-Credentials' header in the response is '' which must be 'true' when the request's credentials mode is 'include'. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.

authentication-included-request:1 オリジン「http://localhost:8080」から「http://localhost:3030/api/authentication-included-request」のXMLHttpRequestへのアクセスは、CORSポリシーによってブロックされた： レスポンスの 'Access-Control-Allow-Credentials' ヘッダーの値は '' です。リクエストの資格情報モードが 'include' の場合は 'true' でなければなりません。XMLHttpRequest によって開始されるリクエストのクレデンシャルモードは withCredentials 属性によって制御される。

WithCredentialns = trueにしてからリクエストでクッキーが送信されるようになった。
しかし上のエラーが出るって感じか。withCredentials = trueをつけたから特別なヘッダがリクエストに付与されたって感じではないな。Cookieヘッダが付与されただけや。

GET /api/authentication-included-request HTTP/1.1
Host: localhost:3030
Connection: keep-alive
sec-ch-ua: "Chromium";v="116", "Not)A;Brand";v="24", "Google Chrome";v="116"
sec-ch-ua-mobile: ?0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36
sec-ch-ua-platform: "macOS"
Accept: */*
Origin: http://localhost:8080
Sec-Fetch-Site: same-site
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: http://localhost:8080/
Accept-Encoding: gzip, deflate, br
Accept-Language: ja-JP,ja;q=0.9,en-US;q=0.8,en;q=0.7,zh-CN;q=0.6,zh;q=0.5
Cookie: counter=2

これを解決するには、レスポンスでAccess-Control-Allow-Credentials: trueというレスポンスヘッダを返せば良い。

ヘッダー追加したら、リソースにアクセスできるようになった。

	response.SetHeader("Access-Control-Allow-Credentials", "true")

レスポンスにちゃんとヘッダが含まれている。

https://qiita.com/att55/items/2154a8aad8bf1409db2b#xhr-を使う場合