Session sharing: 2 JSESSIONID on different paths triggering login issue post update

[space.bo...@gmail.com]

Hi all

 

I've enabled session sharing this way

<?xml version="1.0" encoding="UTF-8"?>

<jboss xmlns="urn:jboss:1.0">

    <shared-session-config xmlns="urn:jboss:shared-session-config:2.0">

        <session-config>

            <cookie-config>

                <path>/</path>

            </cookie-config>

        </session-config>

    </shared-session-config>

</jboss>

 

As such now the JSESSIONID cookie is now on /, whereas before it was on /appName

 Users encounter an issue when updating existing instances with this change (and from WildFly 14 to WildFly 20).

 If the user was logged in before updating, then after update the user has 2 JSESSIONID cookies, one on / and the other on /appName.

 This leads to javax.faces.application.ViewExpiredException: the authentication realm looks for the user info using the value of the JSESSIONID cookie on the old path, which i think doesn't exist anymore, and thus returns "null" as the username.

 

In my app code i've tried to expire the JSESSIONID cookie on the /appName path but when looping over the cookies through HttpServletRequest.getCookies() this precise cookie isn't here.

I guess it could be WildFly protecting its authentication cookie.

I tried cleaning the "old" cookie from the JSF page itself but it's an httpOnly cookie, meaning JavaScript can't access it. 

Do i miss some way to clean this "old" cookie?

Thanks in advance

[Paul Ferraro]

You'll need to use something equivalent to http://httpd.apache.org/docs/2.0/mod/mod_headers.html to remove "old" cookies from the HTTP header before they reach WildFly.

[space.bo...@gmail.com]

Thanks a lot Paul

In between i learnt that:

- on HttpRequest there can't be 2 cookies with the same name on different paths

-- actually in the request all paths are set to null, even if different in reality

- on the HttpRequest, one can set up cookies with same name and different paths

As such in the end, to clear the cookie on the wrong path, 2 cookies were created. One on / with all the data from the incoming JSESSIONID cookie, and one on /appName being expired (max age 0).

It works like a charm :)