JSESSION/HTTPSession vs. application-crafted session ID

In a web application based on propraietery MVC and authorization model, we have recently migrated to Spring MVC. As part of that move, we are also looking at moving awa开发者_高级运维y from a locally created GUID that is passed with each request to a cookie based Session ID.

On the face of it, it looks as if in our case, doing so will be a big disadvantage as the standard JSESSION/HttpSession seems to be the root of all security evils:

1. Session Fixation (In existing code session is only created after succesful login, so we need never invalidate() a sessions.
2. CSRF - Session is never passed as a cookie so this is never a risk (and god, it's a problematic one to handle since there is no real framework or generic solution out therem checked HDIV and CSRFGuard).
3. Testing Useability - QA can easily have multiple users with multiple roles connecting to the same Server, not possible with JSESSION.
4. In consistent HTTPSession creation and invalidation in various Containers (Weblogic, JBOSS and Websphere)
5. Inconsistent JSession handling when moving between HTTP to HTTPS.

So, other than the obvious advantage of "being standard", Any clues as to why would I want to go the JSESSION route?

Not really a categoric answer about why you should or should not use jsession, but stil some remarks regarding your concerns:

1. Your application should not rely on the fact that a session exist or not. It should rely on the fact that the session is valid according to certain rules you put on it (user authenticated, roles assigned to this user, etc...)
2. CSRF is not really a big deal as long as you take care to not use GET for sensible actions, and as you mention Spring MVC, it is quite easy to achieve with it.
3. True, if you only rely on one browser. And as a side note, while manual testing remains a must for some situations, many use cases can benefit from automation, and thus reduce the impact of having to switch from a role to another.
4. Never encounter a problem with that. But I tried to kept the content of the session as small as possible.
5. And that's a good thing. It can prevent you from moving away from your secure connection without noticing it.

Now, whatever the option you'll choose, there will always be some drawbacks. Having a UUID in each request (and thus potentially in each GET URL) does not allow your users to use bookmarks easily. Nor to keep their session alive.

After much discussion analysis and testing, it seems that tleast in my case, a non RESTfull application, with a desktop like RIA UI, and extensive security considration, JSESSION is not the way to go (CSRF mainly) and a better option is a BODY based internally generated key. This does mean though, that the application will be forced to handle timeouts and session invalidation.