[JBAS-2568] Passing a cookie header with a spurious JSESSION

[brian.stansberry]

A member of the community has expressed an interest in helping resolve http://jira.jboss.com/jira/browse/JBAS-2568, so I'm opening this thread to facilitate discussion.

Lepe,

I don't have any really good idea as to what might be causing this issue. The class that controls session creation is the implementation of the Tomcat Manager interface. If a webapp isn't marked as distributable, the implementation used is org.apache.catalina.session.StandardManager -- which is the same class standalone Tomcat uses. That's why it's odd that the behavior is different in embedded JBoss.

To hunt this down, I'd do something like the follows:

0) Double check that this really isn't a problem in Tomcat 5.5.12 standalone. I've already done this twice, but...
1) Look at the StandardManager class and find the code points where it creates session objects and assigns their id. For this you'll need the Tomcat 5.5.12 code, which is available from tomcat.apache.org.
2) Look for places in the JBoss code that call into those code points. These would be in the tomcat module. Best to work with a Branch_4_0 checkout from CVS. At this point don't worry about the o.j.web.tomcat.tc5.session.JBossManager class or it's subclasses JBossCacheManager and JBossManagerCMP -- those are replacements for StandardManager used for distributed sessions and I've already established that the problem exists even if you use StandardManager.

This approach is based on the assumption that if it behaves differently in embedded Tomcat, some JBoss code must be involved in the different behavior. Feel free to question that assumption :-)

[brian.stansberry]

An interesting thing I noticed that may be relevant is that when a session cookie is issued in JBoss for a webapp whose name is, for example, "war1", its path is '/'. In standalone Tomcat its path is '/war1'.

[brian.stansberry]

The cause of this is setting the emptySessionPath attribute to true in the Connector elements in server.xml. In standalone Tomcat by default this is false, in JBoss it's true. If you set it to true in standalone Tomcat it behaves exactly the same as it does in JBoss.

Per the Tomcat docs (http://tomcat.apache.org/tomcat-5.5-doc/config/http.html) setting this attribute to true is useful for portlet specification implementations. In such a setup, sharing a session between webapps can be useful. If sessions are shared, no individual webapp's manager can reject a session id because it didn't create it; the id may have been generated in another webapp.

[moevr]

I don't know if you noticed that, but server session is created even if user sends an empty JSESSIONID as a cookie.

[brian.stansberry]

Is that a serious problem? AFAICT, this would happen in one of two ways:

1) A broken client. I doubt detecting an empty JSESSIONID to help broken clients is going to be a priority.

2) A client deliberately trying to do something bad. Haven't thought hard about it, but don't see what harmful thing a client could do with an empty JSESSIONID.

[nestor.urquiza]

Hi guys,
This is an old post and I have been struggling with this issue for a while trying to understand my best options.

The only thing that can not be argued is that accepting "external to the application session ids" has nothing to deal with "which is the path used for the session cookie to be stored".

Let us take my personal problem to illustrate with a real example. A clustered environment composed by apache using modjk to redirect the requests to a particular tomcat container:
1. Apache receives request http://domain/index.jsp
2. which is translated to http://domain/context/index.jsp and requested to tomcat
3. If Tomcat has emptySessionPath="true" then the whole application works OK but a given client could insert external cookies.
4. If Tomcat has emptySessionPath="false" then the application is protected from external clients to set the session cookie but then any request missing the context part of the URL will be considered part of a new session since the session cookie will be stored in path="/context" instead of path="".

What we really need is:
A. No external cookies allowed.
B. Session cookies to be stored in path="/"

Am I missing something? Thanks in advance for any help!
-Nestor

[brian.stansberry]

Can you just deploy your war with a context path of "/" (see http://wiki.jboss.org/wiki/Wiki.jsp?page=SetupARootContextApp) and then set emptySessionPath="false"?

[nestor.urquiza]

Thanks for the quick response.

I am hosting multiple applications in the same cluster and so it is not possible for me to avoid the Contextualization.

As it is today my cluster is forcing me to use "ugly" URLs since all of the requests must come adding the context to the domain.

-Nestor