Best option for Session management in Java
Asked Answered
C

6

54

Best way managing session in Java. I heard that cookies are not reliable option for this as they gets stored into browser and can be accessed later on? Is this correct? If possible please come up with the answers with the coding example.

Which is the best among:

  • URL Rewriting: Server will add an additional parameter at the end of URL link
  • Hidden parameter in Form: server will add an additional parameter at every form in HTML
  • cookie: Server will ask browser to maintain a cookie.
Countdown answered 9/11, 2009 at 11:10 Comment(2)
Any comment on downvoting me for this questionCountdown
A good blog post for session management journaldev.com/1907/…Smirch
L
74

The session management (client identification, cookie handling, saving session scoped data and so on) is basically already done by the appserver itself. You don't need to worry about it at all. You can just set/get Java objects in the session by HttpSession#setAttribute() and #getAttribute(). Only thing what you really need to take care of is the URL rewriting for the case that the client doesn't support cookies. It will then append a jsessionid identifier to the URL. In the JSP you can use the JSTL's c:url for this. In the Servlet you can use HttpServletResponse#encodeURL() for this. This way the server can identify the client by reading the new request URL.

Your new question shall probably be "But how are cookies related to this? How does the server do it all?". Well, the answer is this: if the server receives a request from a client and the server side code (your code) is trying to get the HttpSession by HttpServletRequest#getSession() while there's no one created yet (first request in a fresh session), the server will create a new one itself. The server will generate a long, unique and hard-to-guess ID (the one which you can get by HttpSession#getId()) and set this ID as a value of the cookie with the name jsessionid. Under the hood the server uses HttpServletResponse#addCookie() for this. Finally the server will store all sessions in some kind of Map with the session ID as key and the HttpSession as value.

According to the HTTP cookie spec the client is required to send the same cookies back in the headers of the subsequent request. Under the hood the server will search for the jsessionid cookie by HttpServletRequest#getCookies() and determine its value. This way the server is able to obtain the associated HttpSession and give it back by every call on HttpServletRequest#getSession().

To the point: the only thing which is stored in the client side is the session ID (in flavor of a cookie) and the HttpSession object (including all of its attributes) is stored in the server side (in Java's memory). You don't need to worry about session management youself and you also don't need to worry about the security.

See also:

Logwood answered 9/11, 2009 at 13:54 Comment(4)
Update: the current HTTP State Management Mechanism specification is RFC 6265, which obsoletes the previous spec RFC 2965. You may update the link in your answer which points to RFC 2965 (in "HTTP cookie spec").Azedarach
@Logwood As per the above answer,if i use url rewritting then what is the way to store values and get values like session.setAttribute() and session.getAttribute().Jecho
@Logwood See I am using mozilla and i have manually blocked accepting cookies (unchecked allow cookies). Then i tried to store to using session.setAttribute("x",x); Now in another page i am using session.getAttribute(x); and the on the page it shows null. After reading your answer,i tried this way and after that i posted a comment.Is not this way to use session attributes?Jecho
@javaprogrammer: apparently you didn't do URL rewriting right.Logwood
M
6

All Java web frameworks support cookies or URL-encoded session IDs. They will chose the correct approach automatically, so there is nothing you need to do. Just request the session object from your container and it will handle the details.

[EDIT] There are two options: Cookies and a special URL. There are problems with both approaches. For example, if you encode the session in an URL, people can try to pass the session on (by putting the URL into a mail, for example). If you want to understand this, read a couple of articles about security and build app servers. Otherwise: Your Java app server will do the right thing for you. Don't think about it.

Misread answered 9/11, 2009 at 11:18 Comment(2)
There are no other options, so the question doesn't make sense.Misread
@Aaron,Did you mean to say that cookies are the only available option?Countdown
I
4

The cookie just stores the session ID, this ID is useless once the session has expired.

Infinitesimal answered 9/11, 2009 at 11:19 Comment(0)
C
2

Servlet specification defines the API for accessing/setting session data in standard J2EE application. Also it defines that session data is stored on the server-side and nothing is transferred to the client except the session identifier. There are 2 mechanisms how session id is transferred:

1) request URL e.g. jessionid=....
2) cookie

Mechanism is determined automatically based on client capabilities.

EDIT. There is no best option, there is servlet specification that defines the way.

Cioban answered 9/11, 2009 at 11:43 Comment(1)
Your servlet spec link appears to be broken, and you should update your question if possible.Star
E
1

Http is a stateless, client-side pull only protocol.

To implement a stateful conversation over it, Java EE Web Server need to hide some information (which is sessionid) in client-side and the mechanism it can use should follow HTTP and HTML spec.

There are three ways to accomplish this goal:

  1. URL Rewriting: Server will add an additional parameter at the end of URL link.
  2. Hidden parameter in Form: server will add an additional parameter at every form in HTML.
  3. cookie: Server will ask browser to maintain a cookie.

Basically, modern web server will have a "filter" to choose which way to use automatically.
So if Server detected that browser already turn off cookie support, it will switch to other ways.

Endblown answered 9/11, 2009 at 12:48 Comment(0)
J
-4

2 important questions:

  1. Which web technology are you using? JSF, Struts, SpringMVC or just plain servlets/JSPs.

    • Servlets/JSPs already give you the session support you need.
      JSP Example: Hello, <%= session.getAttribute( "theName" ) %>

    • I really don't think you have something to worry about cookies, since the data is stored safely in the server and handeling the cookie is done automaticlly.

  2. Is your application installed on a single server?

    • If YES than you have no problem, use the servlet session option.

    • if NO than you gotta find another way to do this. Like using a sticky session, or maybe parse the entire session object in the requests/responses as a field. This option indeed requires you to take security measures.

Jarvis answered 9/11, 2009 at 11:57 Comment(3)
JSF, Struts, SpringMVC are built on top of servlet specification.Cioban
You can call for request.getSession().getAttribute() from anywhere where you have access to request object, not just form JSP.Cioban
This question is related to servlets/JSP.Countdown

© 2022 - 2024 — McMap. All rights reserved.