aspose file tools*
The moose likes JSF and the fly likes jsessionid always appended to urls on first request Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSF
Bookmark "jsessionid always appended to urls on first request" Watch "jsessionid always appended to urls on first request" New topic
Author

jsessionid always appended to urls on first request

Ryan Slominski
Ranch Hand

Joined: Nov 05, 2010
Posts: 33
I'm developing a web application with JSF 2 on GlassFish 3.0.1. I've noticed that when I first deploy the web application and view it with my browser the page initially has the jsessionid in the urls (view source). However, all subsequent navigations return pages which do not have jsessionid in the urls. Any explanation for this?

A related question: I've seen examples where the welcome page (usually index.xhtml) will redirect to a "real" start page like home.xhtml. Is this done to "shake-off" the jsessionid or is there another reason for the redirect?
Ilari Moilanen
Ranch Hand

Joined: Apr 15, 2008
Posts: 198
The jsessionid is the value that identifies the current (http) session for user. It is not only a JSF thing but every java application has to convey to the server the session id so that server knows what session to use.

And the reason why the sessionid is present in the initial requests is probably because at that time the server has not yet had time to put the value to the cookie where it will be after the first request (provided that client has cookies enabled. If client does not have cookies enabled then the jsessionid value will be at every url always).

I don't think that the reason for redirecting is to loose the jsessionid from the url. In my own applications I do the redirect to allow the application to have a standard initial page from where I can redirect where ever I choose (and if later on I decide to change where I want to start then I just redirect the client there using the initial starting page).
Ryan Slominski
Ranch Hand

Joined: Nov 05, 2010
Posts: 33
Thanks for the reply. I am aware of the purpose of the jsessionid and that it is used in urls in the event the client browser doesn't support cookies. I'd really like to know why the first request is always resulting in a page with jsessionid in the urls. If the client is allowing cookies then why not just use them from the beginning? Maybe the server doesn't know whether the client will accept cookies until after the first request? Can anybody point me to a book or literature that confirms this?

I'm not sure I understand your reasoning for using the redirect on your welcome page. If you want to change your welcome page then why not just change your welcome page in the web.xml - no need to do a redirect.
Ilari Moilanen
Ranch Hand

Joined: Apr 15, 2008
Posts: 198
You are correct about the welcome page. I do it also partly because there might be people that try to use the index page regardless of what the welcome page really is... But as I said you are correct and I only told you why I do it, the authors of the books and other example makers have a better reason. Or maybe not, who knows

About your jsessionid problem. You want to remove it since it is a security risk? If that is the reason then maybe the example makers have tought of that too. At least there are a lot of discussions about this issue when you do a Google search.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16014
    
  20

One of the problems with amateur security is that people see risks where there aren't any while missing bigger risks that are there.

The sessionID contains no sensitive information itself. It's just a hash key. Just like a GUID/UUID, its value is that it provides a handle into the server's internal storage, but that handle cannot be used directly, only by the server itself. The only real danger there would be if another user hijacked that handle and used it. While I haven't looked at Tomcat's session-handler source code, I wouldn't be surprised to discover that there are some signature-detecting functions in there to discourage that. And there's no actual requirement that the same identifier string be used on each request/response cycle, so if someone did intercept and abuse in a case like that, it would break the thread to the original client. They'd have to be a full-blown "man in the middle" to avoid problems there.

The sessionID in a cookie is only slightly less visible than the sessionID in a URL, so avoiding sessionIDs on URLs is mostly illusory security.

But as to why the first-request deal? I expect it's because cookie support on the client hasn't yet been confirmed. If you used URL rewriting, you'd have session IDs on all URLs, and that's actually recommended precisely because cookie support on the client isn't guaranteed. The user may be employing a cookie-free browser or have instructed the browser not to use cookies.


Customer surveys are for companies who didn't pay proper attention to begin with.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: jsessionid always appended to urls on first request