2

在我们的 servlet 过滤器链中的某处,有一个过滤器在发送 401 错误时将请求转发到登录页面,作为可用性调整。

我正在尝试将其转换为 Jetty 处理程序,因为有人希望所有 Web 应用程序都通过相同的逻辑进行身份验证,而不是每个 Web 应用程序都必须实现自己的身份验证。

(我们首先使用过滤器方法的主要原因是没有人能够让 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()似乎正确地返回了/. 有趣的是,即使我请求不同的 webapp,它似乎也会这样做,但根据 Javadoc,我必须使用getContext("/")它来确保我获得了根上下文,所以我正在这样做。

获取调度程序也成功。

然后我打电话forward(),这总是向客户端返回 404 响应。

如果我/sign_in直接从 Web 浏览器访问,则会加载表单。

服务器上只有两个上下文:根上下文//sample/我用来测试第二个 webapp 的上下文。所以我知道这/sign_in将在根上下文中,但是为什么forward()在转发到它时会给出 404 呢?

4

1 回答 1

3

结果是一个错误。

https://bugs.eclipse.org/bugs/show_bug.cgi?id=386359

于 2012-08-10T03:40:16.367 回答