Wildfly 18.0.1: JSESSIONID changing

Vikram Chhibber

unread,

Mar 13, 2020, 1:36:07 PM3/13/20

to WildFly

Hi All,

We are in process of upgrading our application from Wildfly 10.1.0 to Wildfly 18.0.1. We are stuck with an issue of Wildfly sending set-cookie in the middle of a session.

After successful login, “j_security_check” response returns set-cookie header and we were expected this to not change in the middle of the session. This has been true so far with WIldfly 10.

The problem now we see is that Wildfly randomly sends set-cookie header in response to any subsequent request and authentication at our application level fails.

We are using distributed web cache as defined in standalone-ha configuration except that the transaction mode is NONE.

<cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">

<replicated-cache name="sso">

</replicated-cache>

<replicated-cache name="routing"/>

<distributed-cache name="dist">

<file-store/>

</distributed-cache>

</cache-container>

Any pointers will be appreciated.

Thanks,

Vikram

Vikram Chhibber

unread,

Mar 14, 2020, 6:21:51 PM3/14/20

to WildFly

Just to add more on this issue. After enabling the logs, I see that when this issue happens, following logs get printed.

14-Mar-2020 13:58:23,743 UTC DEBUG [] [security] (default task-9) || Attempting to authenticate /abc/xyz, authentication required: true

14-Mar-2020 13:58:23,743 UTC DEBUG [] [security] (default task-9) || Authentication outcome was NOT_ATTEMPTED with method io.undertow.security.impl.CachedAuthenticatedSessionMechanism@61a96c52 for /abc/xyz

14-Mar-2020 13:58:23,743 UTC DEBUG [] [security] (default task-9) || Authentication outcome was NOT_ATTEMPTED with method io.undertow.security.impl.BasicAuthenticationMechanism@1634ec4f for /abc/xyz

14-Mar-2020 13:58:23,743 UTC DEBUG [] [security] (default task-9) || Authentication outcome was NOT_ATTEMPTED with method io.undertow.servlet.handlers.security.ServletFormAuthenticationMechanism@4bd204bd for /abc/xyz

14-Mar-2020 13:58:23,743 UTC DEBUG [] [security] (default task-9) || Sending authentication challenge for HttpServerExchange{ GET /abc/xyz}

Thanks

Paul Ferraro

unread,

Mar 15, 2020, 1:48:35 PM3/15/20

to WildFly

The JSESSIONID of a session changes after login to prevent session fixation attacks. Is this the set-cookie to which you are referring?

Additionally, when using a distributed session manager, a set-cookie will be sent any time the ownership of a session changes. This is intentional, so that a load balancer can direct subsequent requests for a a given session to the member that can most efficiently handle that request.

This latter behavior is configurable via the distributable-web subsystem, using a different routing strategy (e.g. routing=local, or routing=none).

Vikram Chhibber

unread,

Mar 15, 2020, 6:46:08 PM3/15/20

to WildFly

Thanks Paul.

We are using legacy PicketBox framework instead of Elytron. In wildfly 10, once successfully authenticated, the JSESSIONID sent as part of "set-cookie" never changed in the middle of the session. Now, we see that Wildfly 18 is sending set-cookie with different JSESSIONID for any random request in the middle of session.

This issue we see in standalone Wildfly mode (Non cluster). Also, even in standalone mode, we use the above mentioned distributed cache configuration.

In Wildfly cluster mode, this might be an issue also though we have not tested it extensively.

Besides the scenario that you mentioned, what are the other scenarios where Wildfly can change the JSESSIONID in the middle of the session and how to disable this behavior? All the requests initiated by browser have valid JSESSIONID as returned after successful authentication.

Vikram Chhibber

unread,

Mar 20, 2020, 6:15:09 PM3/20/20

to WildFly

Hi All,

The issue is resolved now. The problem was having two browser sessions to two different WIldfly instances running on same host but different port in non-cluster mode.

Since browser remembers cookie with scope of host/domain, it was overriding the cookie returned by these two independent http session.