ベアラトークンフィルタはOPTIONS要求を回避する必要がありますか？

Question

認証ベアラトークンが有効かどうかを確認するためにフィルタを使用しています。それにもかかわらず、私はuser-agent（firefox、chrome ...）がCORS OPTIONSリクエストを "実際の"リクエストを行う前にリクエストしようとしているという事実を知っています。

したがって、私のフィルタはこのOPTIONS要求を傍受し、許可ベアラトークンがないため、4xx httpコードで応答します。

OPTIONSリクエストを避ける必要がありますか？ doFilterで

private boolean isExcluded(ServletRequest request) { 
    return ((HttpServletRequest)request).getMethod().equalsIgnoreCase(HttpMethod.OPTIONS); 
} 

：

if (this.isExcluded(request)) 
    chain.doFilter(request, response); 
else 
    //... 

は、この正しいですか？

Answer 1

すべてのCORS処理は、認証前に行う必要があります。これを実装する正しい方法は、の前にの認証フィルタを使用することです。 CORSフィルタで、プリフライトリクエストかどうかを確認します。そうであれば、200で応答し、CORS応答ヘッダーを設定します。その後、フィルターから戻り、それ以上の処理は行われません。プリフライトリクエストでない場合は、チェーン内の次のフィルタに移動します。

CORSフィルタは応答側でのみ実装され、要求を通常どおりに実行させるのは悪い実装です。たとえば、my post hereは本当に悪い例です。だから私はそれがどのようにを実装する必要がありますかの例としてRESTEasy CorsFilterにリンクしています。

CORSプリフライトの詳細については、the MDNを参照してください（動作する方法を理解したい場合は、必ずお読みください）。次に、RESTEasy CorsFilterを調べて、正しく実装されているかどうかを確認します。 JAX-RSフィルタを使用していますが、サーブレットフィルタと連携させるためのアイディアを得ることができます。違いは、JAX-RSフィルタは2つのフィルタ（リクエストとレスポンス）に分割され、サーブレットフィルタはフィルタで使用され、前処理 - >リクエスト - >後処理です。 JAX-RSフィルタは、前処理と後処理のようなものです。

OPTIONSリクエストは必ずしもプリフライトではありません。 Originヘッダーも確認する必要があります。