We upgraded our production environment recently, which included lots of changes. Unfortunately URL based sessions broke in that process. Sessions based on Cookies still work fine.
We assume most customers will allow cookies, they need to log in to use the page anyway. But annoyingly the first request is redirected to the login page which generates a 500 error (view id seems to be null). Since this is the first access the servlet container cannot assume cookies work and redirects to an URL with added “;jsessionid=….”.
The underlying problem is with clustering. We use Tomcat 7 and it is configured for sticky sessions. It adds a period character “.” and its identifier (see jvmRoute) to the jsessionid value. On access using a URL rewritten by prettyfaces such session id’s are not recognised. I investigated further and found the problem: com.ocpsoft.pretty.PrettyContext.JSESSIONID_REGEX is too strict.
Without cluster config session ids match that pattern (e.g. “2437ae534134eeae”). With cluster config they don’t (e.g. “2437ae534134eeae.server1”). I changed that regex to allow periods in the session ID and it seems not just the problem with the initial redirect is solved but url based sessions do work. I only recompiled and replaced that class.
Before: private static final String JSESSIONID_REGEX = “(?i)^(.*);jsessionid=\w+(.*)”;
After: private static final String JSESSIONID_REGEX = “(?i)^(.*);jsessionid=(?w|\.)+(.*)”;
You may want to research what other chars are allowed or common in jsessionid and refine this change. Apparently the servlet spec does not provide info on this, though. Also feel free to rewrite that or-based pattern into an explicit enumeration of allowed chars ([a-zA-Z…]).
For the record: using prettyfaces-jsf2-3.3.0, Tomcat 7.0.? and apache with mod_proxy_ajp and mod_proxy_balancer.
I have considered directy creating an issue for this on google code, but I did not want to create a google account.
thank you very much for this detailed error report. It really seems like the regular expression was a bit too strict.
I just fixed this and pushed the changes upstream. Could you perhaps give version 3.3.3-SNAPSHOT a try? I think everything will work fine with this version. See this wiki page for some documentation on how to use the snapshots: