[フロントエンド]CORSの由来、特徴と用途

12000 ワード

1.同じソースポリシー

あるソースから別のソースのドキュメントまたはスクリプトにインポートされるリソースとのインタラクションを制限するポリシー.デフォルトでは、同じソースからのリソースとのインタラクションのみが許可されます.

1-1. ソース(Origin)

Webコンテンツにアクセスしようとするときに使用するURLのスキーマ(プロトコル)、ホスト名(ドメイン)、およびポートは「ソース」(Origin)と呼ばれます.
次の2つのURLには同じソースがあると言えます.リソースのパスは異なりますが、同じプロトコル(http)、ドメイン(example.com)、ポート番号(デフォルト80ポート)があります.(Internet Explorerはプロトコルとポート番号をチェックしません)

http://example.com/app1/index.html

http://example.com/app2/index.html

1-2. 同じソースポリシーの制限

最近では,OpenAPIなど他のソースのURLにリソースを要求することが非常に多くなっている.同じソースの政策がネットワークの十分な利用を阻害する要因となっている.したがって,異なるソース間の相互作用はCORSの管理下で行うことができる!

⑨ブラウザでソースが異なると判断

例) https://hanamon.kr:442/username/1/例のURLについては、次のように区分できます.https -> プロトコルhanamon.kr -> ホスト(ドメイン):442 -> ポート番号/username/1/ -> URL pathname
上記URLでは、構成元のポイントを区別する基準として「プロトコル」、「ホスト(ドメイン)」、「ポート番号」があります.

2. CORS (Cross-Origin Resource Sharing)

ブラウザは、セキュリティ上の理由でクロスソースのHTTPリクエストを制限します.ブラウザのWeb API XMLHttpRequestとFetch APIも同じソースポリシーに従います.したがって、他のソースからリソースを取得するには、CORSヘッダを含む応答をソースから返す必要があります.

2-1. Preflightリクエスト

OPTIONSメソッドは、実際のリクエストのセキュリティを確保するために、HTTPリクエストをドメイン内のリソースに送信します.このプロセスは、クライアントまたはサーバへのアクセスがユーザーデータに影響を及ぼすことを防止するために実行されます.したがって、Preflightプロシージャを使用して、サーバが許可するソースリストまたは許可する方法を決定する必要があります.

単純総括ソリューション

1. 미들웨어 설치 & 설정 (프론트엔드/백엔드 둘다 해당)
2. 프록시방식 사용 : 브라우저에서 프론트서버로 요청 > 프론트서버에서 백엔드서버로 요청.
프론트에서 요청 header에 Access-Control-Allow-Origin:'도메인:포트 or *(모든도메인)' 옵션 사용

要求ヘッダには、どのソースから送信されたのか、どの方法でサーバに通知されるのか、OriginとAccess Control-Request-Methodが含まれています.アクセス-制御-要求-*ヘッダーは飛行前の要求でのみ送信され、実際の要求を送信するときは含まれません.
サーバは、可能なソースのリスト(*はすべてのドメインにアクセス可能であることを示す)とリクエスト可能なメソッドのタイプを応答ヘッダに送信します.

だから整理するなら?

これは、

Webブラウザで外部ドメインサーバと通信するためのHTTPヘッダに基づく標準化メカニズムである.

クライアントとサーバが異なるドメイン(HTTPヘッダのソースが異なる)であるため、CORS技術が導入された.

CORSは、Webブラウザが作成および実行する異なるドメインのリソースへのアクセスを可能にするセキュリティメカニズムです.

でもあげますか.果たして要るのか.特定のドメインのみ許可されますか?すべてのドメイン名を許可しますか?サーバによって定義されます.(デフォルトではWebブラウザブロックを拡大・縮小しない)

交差ソースリソース共有(ソース間リソース共有)の名義で標準化されています.

これは、

サーバ側がクライアントにリソースの使用を許可するかどうかを決定する方法です.

と同じソースでAJAXを試してみると、CORSの問題は発生しません.

クライアントは、サーバがどのソースリクエストを許可するか分かりません.

クライアントから要求が送信された後、サーバから受信したアクセス制御Allow-Originヘッダ属性によって接続可能かどうかを検証します.

3.CORSの解決方法

3-1. サーバによるCORSの許可

サーバを直接制御できる場合は、Access-Control-Allow-Originヘッダーでクライアント・ソースを許可するだけです.これは最も一般的な方法ですが、OpenAPIのようにサーバを直接制御できない場合は使用できません.

'Access-Control-Allow-Origin': '*',
'Access-Control-Allow-Methods': 'GET, POST, PUT, DELETE, OPTIONS',
'Access-Control-Allow-Headers': 'Content-Type, Accept',
'Access-Control-Max-Age': 10

👉 Requsetヘッダ（クライアント要求ヘッダ）

Origin:要求を送信するページソース(ドメイン)

アクセスコンテンツ要求方法:実際の要求方法

アクセスコンテンツリクエストHeaders:実際のリクエストに含まれるタイトル名

👉 レスポンスヘッダ

アクセス制御Allow-origin:要求のソースを許可(*ワイルドカードはどこでも許可);必要に応じてプロトコル+ホスト+ポート番号を入力)

アクセス制御-すべての資格証明:クライアントがクッキーによる資格証明を要求する場合、true、trueに応答するクライアントは、実際の要求時にサーバ定義の仕様検証値を含むクッキーを同時に送信する必要があります.

アクセス-制御-拡張-リーダー:クライアント要求に含まれるカスタムヘッダ

アクセス制御Max-Agene:クライアントがPreflightリクエスト結果を保存する時間を指定し、クライアントがPreflightリクエスト結果を保存する時間を指定します.この期間中、Preflightリクエストは再発行されません.

アクセス制御-すべてのメソッド:要求を許可するメソッド、デフォルトはGET、POSTです.このヘッダがなければ、GETとPOSTリクエストしかできません.このヘッダが指定されている場合、クライアントがヘッダ値に対応するメソッドである場合にのみ、実際のリクエストが試行されます.

アクセス制御-すべてのHeaders:要求を許可するヘッダー.

const express = require('express');
const app = express();

app.get('/allow-cors', function(request, response) {
 response.set('Access-Control-Allow-Origin', '허용 도메인');
 response.sendFile(__dirname + '/message.json');
});

const listener = app.listen(process.env.PORT, function() {
  console.log('Your app is listening on port ' + listener.address().port);
});

上記の方法が最も一般的ですが、サーバが応答を送信するたびにAccess-Control-Allow-Originヘッダを追加するのは面倒です.Expressを使用してサーバを配備する場合は、Node.jsミドルウェアCOSを取り付けると、毎回手動でCOS関連の設定をする必要はありません.

const express = require('express');
const cors = require('cors');
const app = express();

app.use(cors({ origin: '허용 도메인' }));

3-2. プロキシサーバーの使用

サーバを直接制御できない場合は、プロキシサーバを使用できます.CORSポリシーはブラウザが強制する方法です.サーバがブラウザに関連するヘッダーをいくつかの条件で配置すると、ブラウザはSOPを遵守し、タスクを処理しますが、プロキシサーバは処理しません.このポリシーは、サーバ間の通信では適用されないためです.
また,プロキシサーバはクライアントに応答を送信する際,要求ドメインのソースをAccess-Control-Allow-OriginのソースとするだけでCORS問題を解決できる.