• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

jsessionid in URL

 
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ziyang Zhang
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 knew I would regret that burrito. But this tiny ad has never caused regrets:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic