1.背景
最初の問題を解決するための手段はコントローラに直接クロスドメインSpringbootを追加する@CrossOrigin注釈実装ドメイン間フロントの分離要求の後端部。しかし、ビジネスコードの準備と、トークン開催されたテストセッションを行い、クロスドメインの問題の出現後に再度インターセプタを追加します。私は突然、クロスドメインの問題を傍受するために登場し、なぜテストでも、この点を証明する前に、背景は、クロスドメインリクエストを許可していると言うことは無理だろうか？
2.分析とソリューション
直接バックインターセプタ、要求がトークンヘッダを搬送しない場合、要求が違法である、404ヤードを測定しました。その後、トークンを取得した印刷リクエストヘッダをしなければならないので、その問題が発生したときに、コンソールのトークンがnullの場合、また、何の成功を運ぶないことが見出されたリクエストヘッダを表示するには、ブラウザの開発者ツールを開きます。迎撃までの時間は、完全に（コンソールで、プリントを見ていない値を持っている、である）得られたヘッダ成功にチェックを行うためにビジネスロジックを実現していない、首尾に入手したので、受信の問題を考慮していない、問題の嘘で背景、正確には、インターセプタと言うこと。
なぜブラウザが正常に送信されたトークンはできませんか？CROSの発見は最初の複雑なオプションがスニッフを行うことを要求元の要求CROSを送信する導入でより詳細に手がかり後、サーバはこの要求をサポートしているかどうかをテストするために、要求は要求本当の成功の後に送信されます。しばらくOPTIONSリクエスト要求をもたらす、データを搬送しない、直接リターンステータスコードを傍受され、応答ヘッダは、クロスドメインの問題を解決するために、ヘッダ情報を搬送せず、クロスドメインの問題がありました。
それでは、なぜ最後のこのような状況の先が起こるのだろうか？それは@CrossOriginコメントへのカスタムインターセプタの優先順位ですか？
コントローラ@CrossOriginがマークまたはクロスドメイン・マッピング・リクエストに対応する記録スプリングマッパマッピングレコードは、結果が返される方法でクラス@CrossOrigin注釈、上に標識された場合、その@CrossOriginソースコード注釈を解析することにより、情報へのアクセスAbstractHandlerMethodMappingクロスドメインリクエストが来たときに、要求ハンドラは、クロスドメインリクエストが、そうであれば、クロスドメインを扱うことができるハンドラを返すかどうかを決定する際に、春を取得しました。同等とハンドラ@CrossOrigin原則をまとめると結合好調に推移しました。
ハンドラの実行順序とインターセプタ：だから質問は今を持っていますか？
分析は、すべてのことが判明した後DispatchServlet.doDispatch（）メソッドは、SpringMVCコア入力方法であります迎撃機（そのようなAPI対応するサービスメソッドなど）実際のプロセスにおけるハンドラのpreHandle execute（）メソッド前前記インターセプタのいずれかが偽スキップし、後続のすべてのプロセスを返します。SpringMVCプリフライト要求がPreFlightHandler.handleRequestで処理）（処理され、チェーン全体のプロセスのために設定されています。データがないので、最初のインターセプトされた許可インターセプタとプリフライトリクエスト以来。
すべての取得が要求OPTIONSが要求トークン未満であるので、その解決策は非常に明確である：すべてのオプションがすべてを解放するよう要求します。
//拦截器取到请求先进行判断，如果是OPTIONS请求，则放行
if("OPTIONS".equals(httpServletRequest.getMethod().toUpperCase())) {
System.out.println("Method:OPTIONS");
return true;
}
試験とは、印刷が要求OPTIONSの存在を示す、OPTIONSを促し、そして正常な問題を解決したが見つかりました。
補足1：別の解決策：
フィルタを使用し、問題を解決するためのクロスドメイン@CrosOriginアノテーションを使用しないでください。唯一の問題を解決するためのクロスドメインフィルタのパッケージで使用例CorsFilter、。
CorsFilterは、Webフィルタ容器（は、javax.servlet.Filterを達成）で定義されているので、以前の実行順序にサーブレット、及び入口はSpringMVC DispatchServletあるため、そうフィルタは、第1インターセプタSpringMVC全ての実行されたこと。解析コードはCorsFilter取得CORS構成に応じて扱う単一の要求に対応し、発見しました。
package com.example.pahms.config;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.cors.CorsConfiguration;
import org.springframework.web.cors.UrlBasedCorsConfigurationSource;
import org.springframework.web.filter.CorsFilter;
@Configuration
public class GlobalCorsConfig {
@Bean
public CorsFilter corsFilter() {
CorsConfiguration config = new CorsConfiguration();
config.addAllowedOrigin("*");
config.setAllowCredentials(true);
config.addAllowedMethod("*");
config.addAllowedHeader("*");
config.addExposedHeader("token");
UrlBasedCorsConfigurationSource configSource = new UrlBasedCorsConfigurationSource();
configSource.registerCorsConfiguration("/**", config);
return new CorsFilter(configSource);
}
}
補足2：気付いていない、唯一のアイデアを提供するための方法があります。
AOPを使用すると、プリフライトインターセプト要求をスキップすることができpreHandle（）メソッド、インターセプタサラウンドすべてのカスタムを強化しました。
インターセプタウェブは、それがSpringBoot SpringMVCフレームに依存して、フレームに依存します。実装では、Javaベースの反射機構に、使用することは、サービスまたはメソッドの前に、メソッド呼び出しであるアスペクト指向プログラミング（AOP）を、所属、またはメソッド呼び出しの後に、ダイナミック剤としての方法は、インターセプタであります簡単な実装、メソッドを呼び出す前に、文字列を印刷（またはその他のビジネスロジックの操作を行います）、あなたはまた、メソッドを呼び出した後に文字列をプリントアウトし、例外を投げながらも、ビジネスロジックの操作を行うことができます。インターセプタは、Webベースのフレームワークを呼び出されるので、インターセプタインスタンスは、コントローラのライフサイクルで複数回呼び出すことができながら、業務の数のスプリング依存性注入（DI）を使用することが可能です。しかし、欠点は唯一のコントローラ要求に、直接アクセスなど、いくつかの他の静的リソースに対する要求を傍受することであることはインターセプト処理に方法はありません。
3.おわりに
上記は、私は〜あなたの助けを期待します
