旧疲れたクロスドメインの問題？どのような治療法を見てください

目の前に書かれた「自己修養のIT技術スタッフ」、私は数日以内に良いフィードバックをたくさん受けることを期待していなかった、ご清聴ありがとうございました。学んだ技術的な作業のレッスンの一部と管理の分野での洞察を共有するために戻ってからの時間になります、我々は、為替に引き続き焦点を歓迎します。クロスドメインの最近の問題について尋ねられ、以前にクロスドメインとも知識の片言ので、この記事を扱うための多くの面接は、面接時に参照するために、問題を要約コーマたことがわかっ含みます。

1.クロスドメインとは何ですか

クロスドメインの理解がどのようなものです、我々は最初の「同一生成元ポリシー」の事と呼ばれる場所を理解する必要があり、「同一生成元ポリシー」とは何ですか？これは、必要に応じてアクセス制限を行うための戦略の異なるソースからのリクエストセキュアなWebサイトにアクセスするためのブラウザです。意味「相同」は何と呼ばれますか？私たちは、httpリクエストアドレスは通常、四つの部分含まれていることを知っている：协议://域名:端口/路径それは、そのプロトコルの前で3である、いわゆる相同を、ドメイン名、ポートは同じです。イラスト、我々はアドレスを持っている場合 http://blog.jboost.cn/docker-1.html、それは次のアドレスに相同であるかどうかを確認するには

アドレス	相同かどうか	説明
https://blog.jboost.cn/docker-1.html	異なるソース	異なるプロトコル、HTTP、HTTPS A
http://www.jboost.cn/docker-1.html	異なるソース	異なるドメイン
http://blog.jboost.cn:8080/docker-1.html	異なるソース	異なるポート、ポート80は、デフォルトの1が8080であります
http://blog.jboost.cn/docker-2.html	相同	パスは異なるが、プロトコル、ドメイン名、ポート（デフォルト80）は同じであるが

そして、何の異なるソースのブラウザ要求は、それへのアクセスを制限するために行われていましたか？3つの制限があります。

クッキー、のlocalStorage、及びIndexDBへのアクセス（クラスのNoSQLブラウザは、ローカルデータベースを提供します）
DOMへのアクセス
AJAXリクエスト

クロスドメインアクセスがこの制限を破ることであり、異なるソースからのリソースの要求は、最も一般的には、このようなスプリッタアーキテクチャ、二つの異なるドメインネームサービス、サーバ側インタフェースにAJAX直接アクセスを介して、フロントエンドの前端と後端としてAJAX要求、である、スムーズに行うことができます、クロスドメインの問題でしょう。

2.なぜそこにクロスドメインです

彼は以前にのみ、クロスドメインにこの障壁を設定するには、「同一生成元ポリシー」およびセキュアなWebサイトにアクセスするには、ブラウザで言及されました。そして、3つの前述の制限は、あり、それぞれ、どのようにサイトの安全性を保護します。

クッキーは、のlocalStorageは、IndexDBアクセス制限がローカルストア
我々のシステムのログイン資格情報は、次のような、クライアントに返されるクッキーまたは（例えばRESTリクエスト用など）のトークンの形で直接リターンでSESSIONIDを設定することにより（例えば、ブラウザのフォーム要求として）一般的ですTomcatは、その後、保存するためにクッキーにJSESSIONIDというプロパティを設定することであり、そして他のサイトとの一般的なRESTリクエストトークンは、アクセス制限が存在しない場合、あなたはこれらの文書へのアクセスを取得する可能性があります、前のlocalStorageに保存されていますあまりにも安全ではない不正な要求を開始するためにあなたのアイデンティティを偽造。
DOMへのアクセス制限
、我々は、DOMへのアクセスを制限するので、他のサイト、フィッシングサイトの、特にいくつかの、次のことができない場合は、 <iframe> あなたのサイトのDOMフォームへのアクセスを取得した後、あなたは、このようなユーザー名、パスワードなどの機密情報を入力するために取得...
制限するためのAJAXリクエスト
同一生成元ポリシーの規定を、AJAX要求をのみ、それ以外の場合はエラーになり、相同URLに発行することができます。一部言及した違法なリクエストフォージェリに回避するための制限は、一方で私は、AJAXがあまりにも柔軟性があることを理解し、制限しない場合は、リソースのサイトには、ちょうどあなたのように、他のサイトを自由に使用することが可能になるインタフェースをとることができる理由として他者による私的財はいずれかと私を認める同じを取ります。

要するに、同一生成元ポリシーは、ブラウザによって提供されるセキュリティメカニズムや契約の最も基本的な種類があります。

クロスドメインアクセスを達成するためにどのように3

私たちは通常の基本的なAJAX要求が発生したクロスドメインの問題は、プロキシ、CORS、JSONP他の方法によって解決することができ、一般的な、クロスドメインの問題で、シーンに表示されます。

3.1プロキシ

「同一生成元ポリシーは、」ブラウザ側メカニズムであるので、我々はブラウザをバイパスすることができ、最も一般的なアプローチは、このような、そのような私たちのフロントエンドプロジェクトのドメイン名がhttp://blog.jboost.cnで、サービスとしてnginxの、として、プロキシを使用することですエンドインタフェースドメイン名がhttp://api.jboost.cnで、私たちはnginxの中に以下の構成を提供します

{サーバー
    ＃ポートが
    80を聞く; 
    ＃ドメインの
    サーバー名のblog.jboost.cn; 
    ＃http://blog.jboost.cn/api/xxxすべての要求はhttp://api.jboost.cn/api/xxxに転送されます
    LOCATION 〜^ / API { 
        proxy_pass http://api.jboost.cn; 
    } 
}

フロントエンドサーバによってAJAXリクエストが代わりにクロスドメインの問題を回避するようにhttp://api.jboost.cn/api/xxxがhttp://blog.jboost.cn/api/xxx、異なるソースによってアクセスできるインターフェイス。

3.2 HEARTS

CORSは、クロスオリジンリソース共有速記、クロスドメインのリソースで共有され、CORSはのサービス側の主な作業は、サーバーとブラウザがCORSを達成するために、したがって、（IE10以下を除く）現在のすべてのブラウザのサポートCORSをサポートして必要。春のブートの例では、我々はCorsFilterは、以下により、クロスドメインフィルタをサポートするために登録することができます。

1  @Configuration
 2 @ConditionalOnClass（{サーブレット。クラス、CorsFilter。クラス}）
 3つの パブリック クラスCORSAutoConfiguration {
 4  
5      @Bean
 6 @ConditionalOnMissingBean（名= "corsFilterRegistrationBean" ）
 7  パブリックFilterRegistrationBean corsFilterRegistrationBeanは（）{
 8          UrlBasedCorsConfigurationSource corsConfigurationSource = 新しいUrlBasedCorsConfigurationSource（ ）;
9  
10          CorsConfiguration corsConfiguration = 新しいCorsConfiguration（）。
11         corsConfiguration.applyPermitDefaultValues（）;
12          corsConfiguration.setAllowedMethods（は、Arrays.asList（CorsConfiguration.ALL））。
13          corsConfiguration.addExposedHeader（HttpHeaders.DATE）。
14  
15          corsConfigurationSource.registerCorsConfiguration（ "/ **" 、corsConfiguration）。
16  
17          CorsFilter corsFilter = 新しいCorsFilter（corsConfigurationSource）。
18          FilterRegistrationBean filterRegistrationBean = 新しいFilterRegistrationBean（）。
19          filterRegistrationBean.setFilter（corsFilter）。
20         filterRegistrationBean.setOrder（Ordered.HIGHEST_PRECEDENCE）。
21          filterRegistrationBean.addUrlPatterns（ "/ *" ）。
22  
23          リターンfilterRegistrationBean。
24      }
 25 }

その本質はそこに、ヘッダー応答メッセージにいくつかのプロパティを追加することです

アクセス制御 - 許可原点必要に応じて、クロスドメイン表現が要求元を可能にし、ドメインに特異的であり得る、とすることができる* Anydomainnameを示し
アクセス制御 - 許可 - メソッド必要に応じて、クロスドメインアクセスは、例えばGET、POST、PUTのように、HTTPメソッドを表し、DELETEなど、*ことができる可能にするために、すべてのことを示します
アクセス制御 - 許可 - ヘッダ要求がアクセス・コントロール・リクエスト・ヘッダのヘッダ情報が必要な含まれている場合は、サーバーはすべてのヘッダフィールドをサポートしていることを示し

3.3 JSONP

JSONPブラウザいくつかの標識（例えば、HTMLを使用して <script>、 <img>など）そのようなフロントエンドを追加するなどのsrc属性制限ポリシーの実装特性に相同性を有していません

ます。<script type = "text / javascriptの" SRC = "http://api.jboost.cn/hello?name=jboost&callback=jsonpCallback" />

JSとメソッド定義 jsonpCallback。サーバーは、インターフェイスの内容はJSメソッドである必要が返すjsonpCallbackような呼び出し形式、jsonpCallback({"name":"jboost"})この方法では、jsonpCallbackあなたがデータ・サーバの結果は、実際のメソッドを返し得ることができる{"name":"jboost"}のを。
制限事項JSONPのアプローチも明らかである、1のみが要求GETサポートしています-あなたが見ていない<script>、 <img>ラベルがPOSTリクエストもあり、そして第二に、必要性は、処理のために、サーバのデータ形式を返すように。

4.まとめ

三間の実装のサポート、プロキシ最も簡単な方法は、クライアント、サーバーは侵襲的ではないですが、あなたはより多くのサポート要求元が必要な場合、または第三者のドッキングで、その後の方法は、として有用な薬剤ではありません。CORSは、比較的標準的な治療法であり、また、サービスコードに任意の侵襲的方法なしでフィルタを通ります。偉大な制限JSONPの方法は、唯一のGETサポートし、サーバは、データ・フォーマットのサポートを返すために行う必要があります。あなたは、特定の状況に適した方法を選択することができます。