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

jsessionid in URL

Ziyang Zhang
Ranch Hand

Joined: Jul 17, 2010
Posts: 47
Hi,
Here is my navigation configuration.

My understanding is if I click the sign in button. I will have the url http://XXXXXX/XXX/default.jsf.

But actually I get the following URL when I log in for the first time:
http://XXXXXX/XXX/login.jsf;jsessionid=CEC3FD6EBB4FE3CBBE37AE3322B23051

Why it is login.jsf not default.xhtml? Why I have jsessionid=CEC3FD6EBB4FE3CBBE37AE3322B23051 appended at the end???

I am really very confusing. Thank you very much.
Ziyang

Enjoy life!
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16012
    
  19

Well, first of all, there are a lot of reasons why writing your own login system is a bad idea no matter how many times people use login pages for sample code in J2EE books.

However, the reason for your confusion is that the "*.xhtml"s are resource filenames and the "*.jsf"s are URL references. Navigation rules are URL-based, not resource-based, so you have to use the URL, not the resource that the URL pulls in.

Finally, the "jsessionid" is generated by the web application server. It's used to bind a server session to a web user when it's uncertain that a cookie can carry the session ID. Without a session ID, you can't have a continuous web conversation, since unlike client/server, there's no long-term connection in place between page requests.

You should ignore the jsessionid. It will be removed by the J2EE URL parsers and it will be added by the container if needed, but there's nothing there that applications can or should be messing around with.


Customer surveys are for companies who didn't pay proper attention to begin with.
Ziyang Zhang
Ranch Hand

Joined: Jul 17, 2010
Posts: 47
Tim Holloway wrote:Well, first of all, there are a lot of reasons why writing your own login system is a bad idea no matter how many times people use login pages for sample code in J2EE books.

However, the reason for your confusion is that the "*.xhtml"s are resource filenames and the "*.jsf"s are URL references. Navigation rules are URL-based, not resource-based, so you have to use the URL, not the resource that the URL pulls in.

Finally, the "jsessionid" is generated by the web application server. It's used to bind a server session to a web user when it's uncertain that a cookie can carry the session ID. Without a session ID, you can't have a continuous web conversation, since unlike client/server, there's no long-term connection in place between page requests.

You should ignore the jsessionid. It will be removed by the J2EE URL parsers and it will be added by the container if needed, but there's nothing there that applications can or should be messing around with.

Hi Tim,
Thank you so so much for your clear answer.
I got an article about this: http://randomcoder.com/articles/jsessionid-considered-harmful
Maybe this will also give you some insights.

I think it is really stupid for the server to append the id without noticing me if I like to do that:-)
My understanding is: if cookie is enabled, server will send a cookie including a jsessionid to browser. And after that, every time browser requests for a page, the browser sends the cookie back to tell the server who I am.

But as you said, if cookie is disabled and jsessionid is appended in url, will browser get jsessionid from the url and then send it back to server to tell server who I am? When sending jsessionid back to server, does browser send cookie back to server? Or in other mechanism? If browser sends cookie back, that means browser can still make cookies even he could not accept cookies:-)

Thank you very much! Have a nice day!
Ziyang
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16012
    
  19

The question was asked the other day. Best idea we could come up with without actually trying was that a jsessionId is appended on the first time in as a precaution since full negotation regarding whether cookies are supported might not have been done yet.

Cookies are created by the server and sent to the client. If the client wishes to support cookies, it will then return the cookies on subsequent requests. The server may update some/all of them and send them back. Or delete them and not send them back, depending on application logic. In fact, the java.net Http request class automatically includes cookies when you emit HTTP requests from Java applications without you even having to switch them on!

My thoughts on the randomCoder (For What They're Worth):

jessionId is probably no less secure than cookies, since the only real difference is that one is in the URL itself, but the other is in the attached content. If someone's intercepting, they can get one about as easily as the other. A far better bet is to make sure SSL is already running at that point, so that the whole thing's encrypted against man-in-the-middle attacks.

I certainly HOPE that modern-day search engines have the wit to discount the jsessionId part of a URL. Not to mention a lot of other chunder that frequently comes as part of the URL. After all, this isn't something new and unexpected.

He is right, on the URL rewriting however. If you expect to serve people who have cookies disabled (for paranoia or whatever reason), you MUST rewrite all URLs that you want to participate in the session. The first one that doesn't include jsessionid (meaning it wasn't rewritten) will break the chain.

 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: jsessionid in URL