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?
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).
Joined: Nov 05, 2010
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.
Joined: Apr 15, 2008
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.
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.
An IDE is no substitute for an Intelligent Developer.