クロスドメインの紹介について

独立したフロントとリアのアーキテクチャでは、必然的に、このようなSRC要求http://domain-b.com/image.jpgによるクロスドメイン、サイトhttp://domain-a.com HTMLページのような問題が発生します。多くのページは、異なるドメインからのネットワークCSSスタイルシート、画像やスクリプトや他のリソースにロードされます。

セキュリティ上の理由から、スクリプトクロスオリジンHTTPリクエストの中から起動ブラウザを制限します。例えば、XMLHTTPリクエストとAPIを取得するには、同一生成元ポリシーに従います。これらのAPIのWebアプリケーションの使用がCORSヘッダファイルがない限り、同じドメインのHTTP負荷からアプリケーションをリソースを要求できることをこれが意味。

それのクロスドメインの症状は、異なるドメインまたは異なるポートにあります

CORS（クロスドメイン-起源リソースの共有）（CORS、クロスオリジンリソースの共有）
CORS W3C標準です、それは標準化ブラウザ技術で、サンドボックススクリプトの方法が異なるドメインにWebサービスから来ましたJSONPモードの現代版で回避ブラウザ同一生成元ポリシー、。

シナリオ再現

春ブーツ通常のビルド二つのプロジェクト、サービスを提供するプロバイダの1、消費者のための消費者サービス、8080の最初のconfigureポート、第二の構成は8081で、その後、ハロープロバイダの2つのインターフェイスは、getを提供し、ポストは、次の通り：

@RestController
public class HelloController {
    @GetMapping("/hello")
    public String hello() {
        return "hello";
    }
    @PostMapping("/hello")
    public String hello2() {
        return "post hello";
    }
}

資源/消費者のhtmlファイルの静的なディレクトリの下に作成、簡単なAjaxのリクエストを送信し、次のように：

<div id="app"></div>
<input type="button" onclick="btnClick()" value="get_button">
<input type="button" onclick="btnClick2()" value="post_button">
<script>
    function btnClick() {
        $.get('http://localhost:8080/hello', function (msg) {
            $("#app").html(msg);
        });
    }

    function btnClick2() {
        $.post('http://localhost:8080/hello', function (msg) {
            $("#app").html(msg);
        });
    }
</script>

二つのプロジェクトが開始された、ボタンは次のようにブラウザのコンソールを観察するための要求を送信します。

Access to XMLHttpRequest at 'http://localhost:8080/hello' from origin 'http://localhost:8081' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

制限の生成元ポリシーのため、要求が正常に送信することができません。

ソリューション

フロントエンドコードで使用CORSは、どのような状況下では、クロスドメインを変更することはできません。設定プロバイダーで。

@CrossOriginコメントの設定（推奨されません）

次のように注釈方法を設定すると、特定のドメインに対する要求を受け付けます。

@RestController
public class HelloController {
    @CrossOrigin(value = "http://localhost:8081"，maxAge = 3600)  //origin="*"代表所有域名都可访问  //maxAge飞行前响应的缓存持续时间的最大年龄，简单来说就是Cookie的有效期 单位为秒
//若maxAge是负数,则代表为临时Cookie,不会被持久化,Cookie信息保存在浏览器内存中,浏览器关闭Cookie就消失
    @GetMapping("/hello")
    public String hello() {
        return "hello";
    }

    @CrossOrigin(value = "http://localhost:8081")
    @PostMapping("/hello")
    public String hello2() {
        return "post hello";
    }
}

このアノテーションは、HTTPから受け入れる2つのインタフェースを表す：// localhostを：8081の要求アドレスを、設定が完了し、再びブラウザのコンソールをリクエストを送信し、プロバイダを再起動し、エラーが、消費者がデータを取得することができません。

ブラウザがWebコンソールを要求し、この時点では、次の情報よりも多くのレスポンスヘッダを見ることができます：

// localhostを：：このサーバーは、httpから受信する意欲を表し8081要求をし、この情報を取得するためにした後、ブラウザが行くことはありませんクロスドメインリクエストを制限します。

グローバルコンフィギュレーション

グローバルコンフィギュレーションは、次のようにメソッドaddCorsMappings SpringMVCのクラス構成で書き換える必要があります。

@Configuration
public class WebMvcConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
        .allowedOrigins("http://localhost:8081")
        .allowedMethods("*") //.allowedMethods("PUT", "DELETE","POST","GET")
        .allowedHeaders("*").maxAge(3600);
    }
}

/ **クロスドメインリクエストを処理するために、本出願の方法の全てを表します

allowedMethodsは通過させる要求の数を表し

allowedHeadersは、前記許可要求ヘッダー

クロスドメインフィルタを解決するために、

注釈は、3または@Configurationプロセスが前に削除されていることができます

@Configuration
public class CrosFilter {
    @Bean
    CorsFilter getCorsFilter(){
        CorsConfiguration cors = new CorsConfiguration();
        cors.setAllowCredentials(true);
        cors.addAllowedMethod("*");
        cors.addAllowedOrigin("*");
        cors.setMaxAge(3600L);
        cors.addAllowedHeader("*");
        cors.applyPermitDefaultValues();

        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        source.registerCorsConfiguration("/**",cors);

        CorsFilter corsFilter = new CorsFilter(source);
        return corsFilter;
    }
}

問題

全体の作業工程CORSを理解した後、我々は、ユーザーエクスペリエンスを向上させることが、アヤックスでクロスドメインリクエストを送信するだけでなく、潜在的な脅威が存在し、一般的なCSRF（クロスサイトリクエストフォージェリ）、クロスサイトリクエストフォージェリです。例えば、現在ログインしているWebアプリケーションの操作意図しない攻撃ハイジャックユーザー行い、また、ワンクリックでの攻撃やセッション乗馬と呼ばれる、または一般的にCSRF XSRFと略さCSRF：

次のように銀行振込のURLアドレスは、操作を実行する場合：HTTP :? //Icbc.com/aa BB = ccで、その後、悪意のある攻撃者は、別のサイトで次のコードを配置できます。ユーザーが悪質なサイトを訪問した場合、と彼女はちょうどログイン情報がまだ彼女は苦しむだろう、その後、有効期限が切れていない直前の銀行を訪問しました。

これに基づき、実際にブラウザは、要求は、このような資格情報を持つ要求として、事前に単純な要求、要求に分類され、それが第1のプレリクエストオプションのプローブ要求を送信し、ブラウザが要求を受け入れるかどうかを交渉します。デフォルトでは、クロスドメインリクエストの証明書が必要とされていないが、サーバーは、あなたが効果的にCSRF攻撃を避けることができるように、資格情報を提供するために、クライアントを必要とするように設定することができます。

クロスドメインの問題を解決Springboot--