Cross Origin Resource Sharing (CORS) アクセス制御許可オリジン

1. ブラウザの同一生成元セキュリティポリシー

ブラウザは現在のドメイン内のリソースに対するリクエストのみを許可し、他のドメイン内のリソースに対する不信感を表明します。では、クロスドメインはどのようにみなされるのでしょうか?

リクエストプロトコルhttp,httpsの違い
ドメインのdomain違い
ポートのport違い

分かった、分かった、それはおそらくそうだろう、2 つのよく規制されたメソッドについて話しましょう: CORSdocument.domain JSONP
、window.name、Web ソケット、トラブルを起こすのはやめてください、腰が悪い :)

2. CORS が問題を起こすために出てきた

これは W3C のリーダーによって開発された標準であり、正式名称は「Cross-origin resource Sharing」です。実際、そのほとんどはバックエンド担当者の仕事です。まずプロセス全体を見てみましょう。何が起こったのでしょうか?

その前に、`简单请求` `复杂请求`この二人の子供たちが

単純なリクエスト:
1): リクエストメソッドは次のみです: head、get、post
2): リクエストヘッダーで許可されるフィールド: Accept、Accept-Language、Content-Language、Last-Event-ID
Content-Type: application/x-www-form-urlencoded、multipart/form-data、text のいずれかを選択します/無地

2. 複雑な要求: そうです、上記を満たさない場合は私です!

簡単なリクエスト:

ブラウザ: ドメインを越えたいのですね? サーバーの兄弟にその意思があるかどうか尋ねなければなりません。originリクエストヘッダーに明るいカードを追加する

有个奇怪现象，谷歌游览器在非跨域情况下，也会发送origin字段

リクエストヘッダーのoriginフィールドは現在のドメインです

サーバー: おい、あなたは誰だ、あなたの起源を見てみましょう、はい、それは私の要件を満たしています、放してください! ところで、オヤジのルールを教えておきます！

その中で最も重要なことは、Access-Control-Allow-Originどのドメイン要求が許可されるかを特定することです。もちろん、サーバーに障害が発生した場合、そのようなフィールドはまったく存在せず、トリガーされてXHR、onerrorブラウザーのプロンプトが表示されます。xxx的服务器没有响应Access-Control-Allow-Origin字段

//指定允许其他域名访问
'Access-Control-Allow-Origin:http://172.20.0.206'//一般用法（*，指定域，动态设置），3是因为*不允许携带认证头和cookies
//是否允许后续请求携带认证信息（cookies）,该值只能是true,否则不返回
'Access-Control-Allow-Credentials:true'

上の最初の行で説明されているAccess-Control-Allow-Origin複数の設定方法があります。

この設定*は最もシンプルで失礼ですが、サーバーはセキュリティ上の理由からこれを実行しません。* の場合、たとえ設定がcookies設定XHRされていてもブラウザは送信しません。withCredentials
ドメインを指定します。上図に示すようにhttp://172.20.0.206、一般的なシステムの真ん中に 1 つありますnginxので、これをお勧めします
リクエストドメインとして動的に設定されるので、複数人で共同作業する場合、1つのバックグラウンドに複数のフロントエンドが接続されるので非常に便利です。

withCredentials: Cookie を受信するか、Cookie を送信するかを示します。つまり、値が false の場合、ブラウザーはXHR応答ヘッダーを無視し、ターゲットサイトからの Cookie があったとしてもブラウザーはそれらを送信しません。Set-Cookie

複雑なリクエスト:

最も一般的なケースでは、使用しputてdeleteリクエストするとき、ブラウザーはoption最初に (プリフライト) リクエストを送信しますが、送信しない場合もあります。これについては後でキャッシュについて説明します。

プリフライトリクエスト

単純なリクエストとは異なり、オプションリクエストにはさらに 2 つのフィールドがあります:
Access-Control-Request-Method: このリクエストのリクエストメソッド
Access-Control-Request-Headers: このリクエストのカスタムリクエストヘッダーフィールド

サーバーはチェックに合格すると、次のように応答します。

//指定允许其他域名访问
'Access-Control-Allow-Origin:http://172.20.0.206'//一般用法（*，指定域，动态设置），3是因为*不允许携带认证头和cookies
//是否允许后续请求携带认证信息（cookies）,该值只能是true,否则不返回
'Access-Control-Allow-Credentials:true'
//预检结果缓存时间,也就是上面说到的缓存啦
'Access-Control-Max-Age: 1800'
//允许的请求类型
'Access-Control-Allow-Methods:GET,POST,PUT,POST'
//允许的请求头字段
'Access-Control-Allow-Headers:x-requested-with,content-type'

注:このリクエストに限定されず、サーバーの要件を満たすすべてのリクエストメソッドとリクエストヘッダーが返されますAccess-Control-Request-Method。Access-Control-Request-Headers我一次性告诉你了，别TM问我了

3. 皆さんこんにちは、私は Zha Zhahui です、兄弟なら来てください... 咖咖哒、私は JSONP です

jsonp の原理: script タグを通じて js ファイルを導入します。js ファイルが正常に読み込まれた後、url パラメーターで指定した関数が実行され、必要な json データがパラメーターとして渡されます。一種のコールバックの匂いです！

例：

<script src="http://example.com/data.php?callback=dosomething"></script>

<script type="text/javascript">
    function dosomething(jsondata){
        //处理获得的json数据
    }
</script>

jQueryの使用法

<script type="text/javascript">
    $.getJSON('http://example.com/data.php?callback=?,function(jsondata)'){
        //处理获得的json数据
    };
</script>

JSONP の長所と短所利点
: XMLHttpRequest オブジェクトによって実装される Ajax リクエストのような同一オリジンポリシーによって制限されません。XMLHttpRequest兼容性更好や ActiveX のサポートがなくても古いブラウザで実行でき、リクエストが完了した後は、結果を次のとおりに実行できます。コールバックを呼び出すことで返されます。

欠点: リクエストのみをサポートしますGETが、POST などの他のタイプの HTTP リクエストはサポートしません。クロスドメイン HTTP リクエストのみをサポートし、異なるドメインの 2 つのページ間で JavaScript 呼び出しを行う方法の問題を解決できません。

リンク: https://www.jianshu.com/p/89a377c52b48