7

Jersey ベースの REST サーバーにCORSサポートを実装する必要があります。利用可能な資料と有益なチュートリアルのいくつかを確認しました。人々が使用している 2 つのアプローチを見つけました。

アプローチ-1 :

HTTP応答にヘッダーを追加する 1 つのフィルターを実装する単純で直接的なアプローチCORS(Jersey 固有)

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実装cors-filterのソースコードを調べた

私の質問は、いつどのアプローチをとるべきかということです。アプローチ 1 とアプローチ 2 の欠点は何でしょうか?

私のユースケースは、すべてのオリジン/メソッドが許可され、AuthorizationHTTP ヘッダーがすべてのRESTリクエストの一部になることです。デフォルトのCORS設定のほとんどは私のユースケースで十分だと思われるため、アプローチ1に傾倒していますが、サーバー側で完全なCORS仕様を実装していないと問題が発生するかどうかはわかりません.

4

2 に答える 2

2

あなたの目的には、アプローチ＃1で十分に聞こえます。アプローチ #2 は、リクエスト タイプに基づいて異なる応答がある場合、またはリクエスト情報を検証する場合に適しています。レスポンスがすべてのリクエスト タイプで同じであれば、#1 で問題ありません。実装は基本的にすべてのリクエストが成功することを許可しているため、リクエストが有効であることを確認するために独自のチェックを行う必要があることに注意してください。Authorizationヘッダーを許可しているので、これを認識していて、認証トークンを検証していると思いますか?

于 2013-04-18T14:58:51.610 に答える