LoginSignup
15
5

More than 3 years have passed since last update.

【HTTPヘッダー】CORSの仕組みとGo+GinによるCors設定の実践

Posted at

はじめに

localhost:80で立てたWebサーバー(nginx)から
localhost:8080に立てたAPIサーバー(golang)にリクエストを送った時に、
CORSエラーが発生し、APIが叩けないところでハマったので、
学びとしてまとめます。

そもそもHTTPとは?

HTTP は、 HTML 文書などのリソースを取り出すことを可能にするプロトコルです。これはウェブにおけるデータ交換の基礎をなし、クライアントサーバープロトコルであり、リクエストは受け取り者 (一般にはウェブブラウザー) が生成します。文書全体は、テキスト、レイアウトの定義、画像、動画、スクリプトなど、取り込まれたさまざまなサブ文書から再構成されます。
参考元:HTTP の概要

  • プロトコルの一種
  • ウェブにおけるデータ交換の基礎
  • シンプルで人間が読めるように設計されている
  • HTTPヘッダーで、プロトコルの拡張や検証が簡単
  • ステートレスだけど、HTTP Cookie によってステートフルなセッションを実現
  • HTTP は TCP 標準に依存。
    • TCPはハンドシェイクによって通信の信頼性を担保、つまり通信相手の応答があってはじめて通信を開始するプロトコルを採用

HTTPで制御できること

ざっくりと

  • キャッシュ: html documentsとか
  • オリジン制約のコントロール: CORS(Cross Origin Resource Sharing)の話
  • 認証: Basic認証とか
  • プロキシとトンネリング: World Wide Webにアクセスする時にプロキシや別のネットワークを経由してデータを送ったりできるようにする
  • セッション:クッキーを使ってセッションを保てる

HTTPヘッダーの役割

HTTP ヘッダーにより、クライアントやサーバーが HTTP リクエストやレスポンスで追加情報を渡すことができます。 HTTP ヘッダーは、大文字小文字を区別しないヘッダー名とそれに続くコロン (:)、 値で構成されます。値の前にあるホワイトスペースは無視されます。
参考元:HTTP ヘッダー

なるほど。
HTTPヘッダーはそもそも拡張用のもので、
情報を追加して、独自の制約を持たせたり、
通信のルールを定めて、安心安全かつ用途に合わせたやりとりを実現できる
ってことなんだろうな。

種類 説明
一般ヘッダー /
Generals
リクエストとレスポンスの両方に適用される。
本文で転送されるデータとは関係ない
リクエストヘッダー /
Request Headers
読込むリソースやリクエストしているクライアントに関する詳細な情報を保持
レスポンスヘッダー /
Response Headers
レスポンスに関する追加情報
例えば場所や提供しているサーバーに関するものを保持

CORSとHTTPヘッダーの関係

オリジン間リソース共有Cross-Origin Resource Sharing (CORS) は、追加の HTTP ヘッダーを使用して、あるオリジンで動作しているウェブアプリケーションに、異なるオリジンにある選択されたリソースへのアクセス権を与えるようブラウザーに指示するための仕組みです。ウェブアプリケーションは、自分とは異なるオリジン (ドメイン、プロトコル、ポート番号) にあるリソースをリクエストするとき、オリジン間 HTTP リクエストを実行します。
参考元:オリジン間リソース共有 (CORS)

つまり、CORSに関連する専用のHTTPヘッダー情報があるってことで、
その情報を使って、CORSを実現、かつ制御できると言うことだな。

セキュリティ上の理由から、ブラウザーは、スクリプトによって開始されるオリジン間 HTTP リクエストを制限しています。例えば、 XMLHttpRequestや Fetch API は同一オリジンポリシーsame-origin policyに従います。つまり、これらの API を使用するウェブアプリケーションは、そのアプリケーションが読み込まれたのと同じオリジンに対してのみリソースのリクエストを行うことができ、それ以外のオリジンの場合は正しい CORS ヘッダーを含んでいることが必要です。
参考元:オリジン間リソース共有 (CORS)

知らなかった〜〜〜〜〜orz
自分は、JavascriptのFetch APIを使ってHTTPリクエストを投げたから、
same-origin policyに反して、CORS制限が発動し、
かつ、HTTPヘッダーに適切な設定をしてなかったから、
APIサーバーはリクエストを拒否ってきたのか。

CORSリクエストを成功させるには?

各種HTTPヘッダー情報を適切に設定する必要がある。

種類 説明
Access-Control-Allow-Origin リクエストの送信元の指定 http://localhost
Access-Control-Allow-Credentials 資格情報(Cookie、認証ヘッダー、TLSクライアント証明書)の送信をOKするか true
Access-Control-Allow-Headers リクエスト間に使用できるHTTPヘッダーを指定 Accept, Content-Type
Access-Control-Allow-Methods 使用できるメソッドを指定 GET, POST, HEAD
Access-Control-Expose-Headers ヘッダー名を羅列して、レスポンスの一部として開示するものを指定
既定のセーフリストは7つだけだから
Content-Length
Access-Control-Max-Age プリフライトリクエストの結果をキャッシュしてよい期間を指定 86400
Access-Control-Request-Headers 実際のリクエストで使うHTTPヘッダーをサーバーに知らせる目的
プリフライトリクエストで使用
Accept, Content-Type
Access-Control-Request-Method 実際のリクエストで使うHTTPメソッドをサーバーに知らせる目的
プリフライトリクエストで使用
GET, POST, HEAD

CORSでプリフライトを引き起こさないためには

そもそもプリフライトとは

「プリフライト」リクエストは始めに OPTIONS メソッドによる HTTP リクエストを他のドメインにあるリソースに向けて送り、実際のリクエストを送信しても安全かどうかを確かめます。サイト間リクエストがユーザーデータに影響を与える可能性があるような場合に、このようにプリフライトを行います。
参考元:プリフライトリクエスト

安全確認のためのリクエストってことすな。

プリフライトしない条件

以下のすべての条件を満たすもの。

  • メソッド
    • GET
    • HEAD
    • POST
  • HTTPヘッダー
    • Accept
    • Accept-Language
    • Content-Language
    • Content-Type
      • application/x-www-form-urlencoded
      • multipart/form-data
      • text/plain
    • DPR
    • Downlink
    • Save-Data
    • Viewport-Width
    • Width
  • XMLHttpRequestUpload にもイベントリスナーが登録されていない
  • ReadableStream オブジェクトが使用されていない

実際に確認してみる。

とりあえずgin+corsで確認してみる。
※下記、コードは色々、省略してるので、コピーでは動きません。

fetch
//一部の記述です
fetch(url_string + queryParams,
        {
          method: 'GET',//<-これをいじって検証
          mode: 'cors',
          headers: {
            'Content-Type': 'application/json',//<-これをいじって検証
          }
        })
main.go
import (
    "github.com/gin-contrib/cors"
    "github.com/gin-gonic/gin"
)

func main() {
    // Start HTTP server
    r := gin.Default()

    // ここからCorsの設定
    // *****CORS設定をいじくって検証********
    r.Use(cors.New(cors.Config{
        // アクセス許可するオリジン
        AllowOrigins: []string{
            "http://localhost",
        },
        // アクセス許可するHTTPメソッド
        AllowMethods: []string{
            "POST",
            "GET",
            "OPTIONS",
        },
        // 許可するHTTPリクエストヘッダ
        AllowHeaders: []string{
            "Content-Type",
        },
        // cookieなどの情報を必要とするかどうか
        AllowCredentials: false,
        // preflightリクエストの結果をキャッシュする時間
        MaxAge: 24 * time.Hour,
    }))
    r.GET("/scrape", scrapeText)

    if err := r.Run(":8080"); err != nil {
        log.Fatal(err)
    }
}

リクエストではContent-Typeを送るけど、サーバーサイドでは許していないパターン

スクリーンショット 2021-03-25 18.52.14.png

Request header field content-type is not allowed by Access-Control-Allow-Headers in preflight response

ヘッダーを許可してないよと怒られた。

リクエストではPUTで送るけど、サーバーサイドでは、PUTメソッドを許していないパターン

スクリーンショット 2021-03-25 19.09.18.png

Method PUT is not allowed by Access-Control-Allow-Methods in preflight response

PUTメソッド許可してないよと怒られた。

"リクエストではContent-Typeを送るけど、サーバーサイドでは許していないパターン

スクリーンショット 2021-03-25 19.13.47.png

Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource...

Originを許可してないよって怒られた。
※オリジンとリファラーって最後の/があるかないかで微妙に違うから気をつけないと。。。

ちなみに、条件に合わせたらプリフライトが飛ばなくなった

'Content-Type': 'text/plain',に変更してみたら、リクエストが1回のみになった。

スクリーンショット 2021-03-25 19.21.30.png

変更前は、プリフライトある場合は、2回APIがたかれている。
スクリーンショット 2021-03-25 19.24.19.png

application/jsonは許可されていないので、
いわゆるSimple requests(プリフライトが怒らないやつ)の条件から外れてしまうわけですねぇ

まとめ

CORSでハマって、なんやねんなんやねん、パソコンたたき割ったろかぁぁぁあああ!!!
って数時間ずっと苦しみましたが、なかなかの学びと成果につながりました。

検証したから、しっかりと身を持って体験できたことで、実感が湧きました。

変毒為薬っすな。

HTTPヘッダーさんとCORSさんが、こんな仕組みになってるなんて知らなかったワイ✨

以上、ありがとうございました。

引き続き頑張ります٩( ᐛ )و

15
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
15
5