Honor Admin Session Timeout for the admin console REST token

[renatsaf]

Problem

Setting Admin Session Timeout to 0 ("never") in the admin console still logs the user out after ~30 minutes of inactivity (issue #24982).

Root cause

The console relies on two independent timers:

1. The HTTP servlet session, correctly governed by das-config/adminSessionTimeoutInMinutes via GuiUtil.initSessionAttributes() (0 → setMaxInactiveInterval(-1), never expires).
2. The REST session token used for all backend REST calls, created in SessionsResource with a lifetime taken solely from rest-config/session-token-timeout (default 30 min) — it never consulted the Admin Session Timeout setting.

So with Admin Session Timeout = 0, the HTTP session never expired, but the REST token still lapsed after 30 minutes. The next click made a REST call that returned 401, which RestUtil handles by invalidating the session and redirecting to login. The defaults were inconsistent too (GUI 60 min vs token 30 min), so the documented GUI timeout was effectively overridden by the token.

Fix

• RestSessionManager: a non-positive timeout now means "never expire" (previously 0 made the session inactive immediately).
• AdminConsoleAuthModule: passes the configured adminSessionTimeoutInMinutes when creating the REST session, so the token lifetime matches the GUI session.
• SessionsResource: honors the timeout supplied by the (already admin-authenticated) login request, falling back to the existing session-token-timeout default for other REST clients — so direct REST API callers are unaffected.

Testing

• The three changed modules compile (common-util, rest-service, admingui/common).
• Logic verified by code review. A full runtime check requires waiting out the timeout against a running domain and was not performed.

Fixes #24982

🤖 Generated with Claude Code

[OndroMih]

The solution probably works but I have security concerns. The Admin GUI web app is a client to the HTTP admin backend and the current solution is that the web app retrieves the session timeout from the configuration and passes it to the backend as a parameter.

Sending the timeout for a token by a client is not a good security practice. it could be potentially exploited, even though SessionsResource is only accessible by an authenticated user.

Is it possible to read the session timeout directly in the SessionsResource class on the backend, instead of passing it from the Admin web app?

Something like:

• Remove sessionTimeoutInMinutes from the payload in AdminConsoleAuthModule
• Read adminSessionTimeoutInMinutes directly in SessionsResource (via injected Domain or DasConfig)
• Decide explicitly whether adminSessionTimeoutInMinutes should apply - it should apply only to console-originated ones, when NetUtils.isLocal(grizzlyRequest.getRemoteAddr()) && grizzlyRequest.getHeader("X-GlassFish-Remote-Host") != null. The request must be from the local host (Admin GUI is always on the same host) and it must have the header, which is only sent by the Admin GUi, not by other clients like asadmin or REST clients.

[renatsaf]

Thanks @OndroMih, good catch — agreed that letting the client set its own token lifetime is the wrong place for it. I've reworked it along the lines you suggested:

• AdminConsoleAuthModule is reverted: it no longer reads or sends sessionTimeoutInMinutes.
• SessionsResource now reads adminSessionTimeoutInMinutes directly from DasConfig (via the base service locator) on the backend.
• It applies that timeout only to console-originated requests, detected the same way GenericAdminAuthenticator does: NetUtils.isLocal(grizzlyRequest.getRemoteAddr()) && grizzlyRequest.getHeader("X-GlassFish-Remote-Host") != null. Only the co-located admin console satisfies both; asadmin and other REST clients fall through to the existing rest-config/session-token-timeout default and can no longer influence their token lifetime.
• The RestSessionManager change (non-positive timeout = never expire) is unchanged.

A config-read failure is logged at FINE and falls back to the rest-config default, so it can't break login. PTAL.