Session cookie path in JBoss 6
fr0w Jul 29, 2011 3:00 PMSome contextualization:
I used to run my Seam 2 apps (lots of them) in a clustered JBoss 4.2.3.GA environment with Apache+mod_jk to provide load balancing, but now I'm migrating to JBoss 6 and Apache+mod_cluster.
In JBoss 4.2.3.GA, the session cookie was created with its path equal to "/" and this seemed to work just fine with my apps.
When the user first reaches /app1 a session cookie (ex: JSESSIONID = abcdefgh.jboss01) is created tying the user to a specific instance of JBoss. Now even if the user access /app2 this request is still going to be handled by "jboss01", which simplified a lot of things for me.
Now that I've migrated to JBoss 6, I noticed that the session cookies are now created with path equal to "/context-path", so accessing /app1 and creating a session result in a cookie like this: "JSESSIONID = abcdefgh.jboss01, path=/app1", so whenever the same user tries to access /app2 there is chance that the load balancer will redirect him to another instance of JBoss (ex: jboss02) due to the fact that the previous cookie is specific to a certaint context-path.
I found out that the Servlet 3.0 spec provides a new configuration option that allows me to override some seesion cookie configuration including the path!
Here is how my web.xml looks now:
<session-config> <cookie-config> <path>/</path> </cookie-config> </session-config>
In order to have JBoss 6 accept that, I had to change my XML header to:
<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaeehttp://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" version="3.0">
If I kept version="2.5", JBoss would complain while deploying the app.
So here are the questions:
- Does changing the version in the web.xml changes any behaviour in the container that could cause Seam 2, which is a Servlet 2.5 fwk, trouble? Or is this just something that affects the parsing of the XML?
- Does setting the path of the Cookie to "/" present a security problem of some sort? Why was this behaviour changed?