6

特定のエンドポイントでの認証を処理する前にフィルターを使用するだけでなく、末尾のスラッシュを追加する前にフィルターを使用することを結び付けています。

これが私のルーティングコードです：

// Add filter to all requests which adds a trailing slash if it is missing //
before("*", Filters.addTrailingSlashes);
path("/api", () -> {
    // Authentication Intercept //
    before("/*", AuthenticationIntercept.authenticationIntercept);

    // Sampling Endpoints //
    get(Path.Web.SAMPLES_FETCH_LATEST, SamplingController.fetchLatestSamples, new JsonTransformer());
    get(Path.Web.SAMPLES_FETCH_FOR_DEVICE, SamplingController.getLatestSamplesForDevice, new JsonTransformer());
});

次に、次のエンドポイントにヒットします。

ローカルホスト:4567/api/samples/10

addTrailingSlashes が最初に呼び出されます。次に、認証フィルターが呼び出され、今度はリクエスト エンドポイントとして localhost:4567/api/samples/10/ を使用して addTrailingSlashes が再度呼び出され、最後に認証フィルターが再度呼び出されます。

これは予想される動作ですか？私がしたいのは、 addTrailingSlashes が一度呼び出されてスラッシュが追加され、認証フィルターが一度だけ呼び出されるようにリクエストを一度転送することです。

どんなアイデアでも大歓迎です。

ありがとう、ネイサン

4

1 に答える 1

2

私は同じ問題を抱えていましたが、別のタイプのフィルターを使用していました。ブラウザが 2 つの呼び出しを行うことが判明しました。

アプリのルート パスにサービスが構成されていないため、マップされていないものも含め、すべての呼び出しに対してフィルターがトリガーされているようです。

マップされていない他のパスを使用して、次のようなことを試してみることを確認しました。

http://yourdomain.com/aaa/bbb

この呼び出しにより、フィルターが 2 回トリガーされました。存在しないサービスの最初のものであり、favicon.ico を取得するものです。

Fiddler などの http 監視ソフトウェアを使用して、どのような呼び出しが行われたかを確認すると便利です。

フィルターで favicon のケースを確認して無視するのは非常に簡単です。呼び出しが有効なサービスに対して行われたことを確認するには、もう少し手間がかかります。多分それを行うためのより良い方法があります。

于 2018-03-01T16:23:36.260 に答える