jetty-9.2.2 に CometD-3.0.1 をデプロイしています。
すべてのリクエストに対して呼び出したい独自のフィルターがあります。これらのフィルターを特定の順序で web.xml に指定しました。
しかし、WebSocket では、コンテナはアップグレード リクエストを処理する方法を見つける必要があります。Jetty では、これは常に ServletContainerInitializer によって最初のフィルターとして追加されるサーブレット フィルターによって行われます。したがって、私の場合、チェーンの前にある WS フィルターがフィルターに到達する前にアップグレードを実行するため、アップグレード リクエストがフィルターに到達することはありません。
Jetty の WS フィルターの前にフィルターが最初に呼び出されるようにするにはどうすればよいですか?
ありがとう、アヌジ
つまり、websocket のアップグレードでサーブレット フィルターを実行することはできません。
WebSocket のアップグレードをフィルターで処理するという jetty の選択は、サーブレットと WebSocket 仕様の特定の実装にすぎません。他の実装では、異なる手法が使用される場合があります。
これについて理解すべきことが 2 つあります。
コンテナーが既知のパス マッピング / パス仕様で WebSocket エンドポイントを構成した場合、到着したアップグレード リクエストは、すべてのサーブレット処理の前に処理されます。Jetty は内部フィルターを介してこれを行うことを選択しました。他の実装では、サーブレット チェーンに渡す前に特別な処理でこれを行います。
Websocket アップグレードのサーブレット フィルタリングは、サーブレット仕様の早い段階で推奨されませんでした。これは、フィルターが実行できる変更のほとんどが、Websocket アップグレードに問題を引き起こすためです。問題を引き起こすことが知られているいくつかのコード パスを拒否することについて簡単な話がありました (リクエスト コンテンツまたはレスポンス コンテンツへのアクセス、リクエストまたはレスポンスでのヘッダーの設定など)。しかし、これは侵略的すぎることが判明したため、できず、がっかりします。
ここで、websocket のアップグレードが発生せず、エラーが発生しない場合は、サーブレット処理チェーンがその要求に対して開始されることを知っておく必要があります。
ここでの典型的な問題は、一部の人々がフィルターを中心にセキュリティを構築していることです。これはサーブレットには適していますが、WebSocket には適していません。
この場合、あなたの前にいくつかの仕事があります。
次のいずれかを選択:
また