6
JerseyベースのRESTサーバーでCORSサポートを実装する必要があります。私は利用可能ないくつかのmaterialと有益なtutorialsを行った。 は、私は2つのアプローチの人々が使用しているが見つかりました：CORS Javaサーバー側実装
アプローチ-1：
シンプルかつ直接的なアプローチ応答にCORSヘッダを付加して1つのHTTPフィルタ（特定ジャージー）
public class ResponseCorsFilter implements ContainerResponseFilter {
public ContainerResponse filter(ContainerRequest req, ContainerResponse contResp) {
ResponseBuilder resp = Response.fromResponse(contResp.getResponse());
resp.header("Access-Control-Allow-Origin", "*")
.header("Access-Control-Allow-Methods", "GET, POST, OPTIONS");
String reqHead = req.getHeaderValue("Access-Control-Request-Headers");
if(null != reqHead && !reqHead.equals(null)){
resp.header("Access-Control-Allow-Headers", reqHead);
}
contResp.setResponse(resp.build());
return contResp;
}
}
を実装アプローチ-2：
完全実装CORSプリフライト要求処理とすべてのヘッダーサポートの仕様に従います。そのようなオープンソースのJava実装の1つの検査されたソースコードcors-filter
私の質問はどのようなときに取られるべきですか？アプローチ-1とアプローチ-2の欠点は何でしょうか？
私の使用例はすべての起源/方法が可能であり、Authorization HTTPヘッダーはすべてRESTリクエストの一部になります。デフォルトのCORS設定のほとんどが私のユースケースで十分だろうが、サーバ側で実装された完全なCORS仕様を持たないのであれば、何か問題が発生するかどうかわからないので、私はアプローチ-1に傾いている。
感謝は、はい各要求は、任意の処理を行う前に検証する受信側のサーバーAuthorizationヘッダーに格納されている公開トークンでタグ付けされているものとします。 – harsh