Describe the bug

With RabbitMQ 4.2.5-management, the management UI OAuth login page can still fail with ReferenceError: strict_auth_mechanism is not defined.

This happens when the management UI renders login_oauth.ejs and the page context does not include strict_auth_mechanism / preferred_auth_mechanism.

I noticed PR #15148 ("Do not validate auth mechanism if not present") and expected this path to be safe in the 4.2.x line, but in our environment the login page still crashes before the OAuth flow can proceed unless we override the template.

Environment:

• RabbitMQ image: rabbitmq:4.2-management
• Actual broker version: 4.2.5
• Deployment: Docker Compose
• Enabled plugins: rabbitmq_management, rabbitmq_prometheus, rabbitmq_auth_backend_oauth2
• IdP: a generic OIDC provider
• OIDC flow: Authorization Code + PKCE

Reproduction steps

1. Start RabbitMQ 4.2.5 with rabbitmq_management and rabbitmq_auth_backend_oauth2.
2. Configure management OAuth with OIDC enabled, but do not explicitly provide strict_auth_mechanism or preferred_auth_mechanism.
3. Open the management UI login page.
4. Observe the browser console and the broken login screen.
5. The page crashes before the OAuth flow can proceed, with ReferenceError: strict_auth_mechanism is not defined coming from login_oauth.ejs.

Expected behavior

If no auth mechanism is provided, the management UI should render safely and continue with the default OAuth login flow.

The login page should not assume strict_auth_mechanism / preferred_auth_mechanism are always defined in the template context.

Additional context

Relevant configuration (sanitized):

auth_backends.1 = oauth2
auth_backends.2 = internal

auth_oauth2.resource_server_id = urn:rabbitmq:example:admin
auth_oauth2.verify_aud = false
auth_oauth2.issuer = https://example.com
auth_oauth2.preferred_username_claims.1 = name
auth_oauth2.preferred_username_claims.2 = email

management.oauth_enabled = true
management.oauth_disable_basic_auth = false
management.oauth_client_id = <redacted>
management.oauth_scopes = openid profile urn:rabbitmq:example:admin.tag:administrator
management.oauth_authorization_endpoint_params.resource = urn:rabbitmq:example:admin
management.oauth_authorization_endpoint_params.audience = urn:rabbitmq:example:admin
management.oauth_token_endpoint_params.resource = urn:rabbitmq:example:admin
management.oauth_token_endpoint_params.audience = urn:rabbitmq:example:admin

Browser console:

ReferenceError: strict_auth_mechanism is not defined
    at Object.process (.../js/tmpl/login_oauth.ejs)
    at EJS.render (...)
    at format (.../js/main.js)
    at render_login_oauth (.../js/main.js)

The shipped template contains checks like:

<% if (strict_auth_mechanism !== undefined && strict_auth_mechanism.type === "oauth2") { %>

If the variable is not present in the EJS context at all, this throws a ReferenceError instead of evaluating to false.

Current workaround/hack:

• override the shipped login_oauth.ejs template
• replace direct variable access with guarded checks such as typeof strict_auth_mechanism !== "undefined"

After applying that template override, the management UI rendered correctly and the native OIDC flow could continue.

There were other integration issues in our rollout, but they were separate and configuration-related:

• TLS hostname verification for the IdP connection
• missing post-logout redirect URI in the IdP client configuration

Those are not the issue being reported here.

This report is specifically about the management UI login template crashing when strict_auth_mechanism / preferred_auth_mechanism are absent from the template context.

If helpful, I can also provide the exact login_oauth.ejs workaround patch we had to mount into the container.