Wildfly 8.1.0: jsessionid squashed by changing content directories

[aafritz]

This is a strange one so stick with me.

The application worked fine in wildfly 8.0.0.Final. The first startup on wildfly 8.1.0.final it worked fine. On the second and subsequent startups, my authentication system failed. The user could log in, but navigating to other content would result in either a redirect to the login page, or "requires login" content not being rendered on the page (only the publicly visible content being shown- that is a partial rendering of the page).

I initially assumed the issue was some incompatibility between prettyfaces as wildfly 8.1.0 and stripped out prettyfaces. The problem persisted. I then assumed the problem was my authorization filter. Removing/gutting it had no effect.

Eventually after several days of hacking, I came across some posts about wildfly 8.0.0.CR1 (and other pre-final versions) having issues with cookie based session ids. Some people said switching to URL based session management fixed the problem for them. I tried this. It fixed my problem but isn't acceptable for the production system. Other people indicated that changing the cookie name from the default fixed the problem.

In my case, changing the cookie name fixes the problem on THE NEXT STARTUP ONLY. If I wish to restart the server, I have to change the cookie name or the problem (the session is not available in sub-directories of my web content) returns. Simply assigning the cookie a random name fixes the issue, but obviously isn't practical in the real world.

Question: What is going on? How do I begin to trouble shoot this beyond where I am now? I've been working on this problem (indirectly and directly) for more than 2 weeks...

[jaikiran]

What kind of authentication system do you have in place? Standard Java EE authentication schemes like FORM based which restrict access to URL based resources? Is that a application specific cookie or the standard session id cookie that the containers use, which is causing problems?

When you run into this problem on certain pages, can you enable client side tools in the browser (like Firebug for Firefox and the Developer tools in Chrome) to get the cookies that are set when you visit that page?

[ctomc]

Maybe you are hitting this [WFLY-3448] Session ID change with sub-directories using "/" context (virtual host) - JBoss Issue Tracker

[aafritz]

@Tomaz Cerar: That ticket describes my problem perfectly. Apparently the bug with setting the default cookie path is intermittent. Setting an explicit cookie path is the real work around apparently and safe even when they fix the code. Thanks.