ErrorPageErrorHandler does not resolve configured 403 error page for authorization failures

[ChrisHuebsch-FLIG]

Jetty version(s)
12.0.39

Jetty Environment
ee10

HTTP version
HTTP 1.1(?)

Java version/vendor (use: java -version)
OpenJDK 64-Bit Server VM Temurin-17.0.15+6 (build 17.0.15+6, mixed mode, sharing)

OS type/version
Win 11

Description

We are using Jetty 12.0.39 (EE10) with OpenID authentication and role-based authorization.

A custom error page is configured in web.xml:

403 /accessDenied

The mapping is correctly registered. While debugging, the WebAppContext contains:

_errorPages = {403=/accessDenied}

The target resource (/accessDenied) is reachable and not protected by security constraints.

However, when authorization fails because a user does not have the required role, Jetty always displays the built-in minimal 403 page instead of dispatching to the configured error page.

The authorization failure originates in SecurityHandler:

if (mustValidate && !isAuthorized(constraint, authenticationState))
{
    Response.writeError(
        request,
        response,
        callback,
        HttpStatus.FORBIDDEN_403,
        "!authorized");
    return true;
}

While debugging ErrorPageErrorHandler, we observed that:

request.getAttribute(Dispatcher.ERROR_STATUS_CODE)

returns null.

As a result, ErrorPageErrorHandler does not find the configured mapping for HTTP status 403, despite the mapping being present in _errorPages.

We also noticed that the generated error request appears to contain:

org.eclipse.jetty.server.handler.ErrorHandler.ERROR_STATUS
(see org.eclipse.jetty.server.handler.ErrorHandler.ErrorRequest)

but ErrorPageErrorHandler later looks for:

org.eclipse.jetty.ee10.servlet.Dispatcher.ERROR_STATUS_CODE

This may indicate an inconsistency between the attributes written during Response.writeError() processing and the attributes expected by ErrorPageErrorHandler.

Expected behavior:

• Authorization failures resulting in HTTP 403 should be dispatched to the configured error page (/accessDenied).

Actual behavior:

• Jetty displays the default minimal 403 page.
• The configured mapping is ignored.

Could this be a bug, or is there an additional configuration required for SecurityHandler authorization failures to participate in normal error-page dispatching?