サーブレットフィルタのチェーンのどこかに、使いやすさの微調整として、401エラーが送信されたときにリクエストをサインインページに転送するフィルタがあります。
すべてのWebアプリケーションが独自の認証を実装するのではなく、すべてのWebアプリケーションが同じロジックで認証されることを誰かが望んでいるため、これをJettyハンドラーに変換しようとしています。
（そもそもフィルターアプローチを使用している主な理由は、Jettyのコンテナーレベル認証をまったく機能させることができなかったためです。Windows認証または組み込み認証を選択できるため、次のことが可能になりたいと考えています。実行時にこれらを切り替えるために、Jettyでそれを機能させる方法を理解することはできませんでした。）
Jettyハンドラーには、次のようなロジックがあります。
private void handleErrorBetter(HttpServletRequest servletRequest,
HttpServletResponse servletResponse)
throws ServletException, IOException {
if (isPageRequest(servletRequest)) {
ServletContext rootContext = servletRequest.getServletContext().getContext("/");
RequestDispatcher dispatcher = rootContext.getRequestDispatcher("/sign_in");
dispatcher.forward(servletRequest, servletResponse);
} else {
// ...
}
}
servletRequest.getServletContext()のコンテキストを正しく返すように見えます/。興味深いことに、別のWebアプリをリクエストしてもこれを行うように見えますが、JavadocによるとgetContext("/")、ルートコンテキストを確実に取得するために使用する必要があるため、これを実行しています。
ディスパッチャの取得も成功します。
次に電話をかけるforward()と、これは常にクライアントに404応答を返します。
/sign_inWebブラウザーから直接アクセスすると、フォームが読み込まれます。
サーバーには、ルートコンテキスト/と/sample/2番目のWebアプリのテストに使用しているコンテキストの2つのコンテキストしかありません。だから私はそれ/sign_inがルートコンテキストにあることを知っていますが、なぜforward()それに転送するときに404を与えるのですか？