• Post Reply Bookmark Topic Watch Topic
  • New Topic

How do sessions work in general ?

 
Sreyan Chakravarty
Ranch Hand
Posts: 65
Firefox Browser MyEclipse IDE Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Okay I am new to web-programming in general and am confused about how sessions work-:

1) Are sessions stored only on the client computer ? If so then if cookies are disabled then if browsers only store the session how are they able to remember the exact JSESSIONID ? Also how does the server (like Tomcat) remember which JSESSIONID belongs to which user ? Where does it store that information ?

2) If the server also stores the session information then how fast does it become out of date ?

3) If a client has cookies disabled does the server maintain a key-value pair of the IP and the session-id, so that if the same client logs in then the same session-id will be appended ?

4) When does the web-container make the decision of using cookies or the encodeURL() method to embed the session info ?

I use Tomcat 8.0 for now.
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 35716
412
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1) No. Cookies are stored on the client (if you use them.) Sessions are stored on the server. They can be referenced by a cookie or parameter (JSESSIONID.) It is better not to use the parameter because then the session id shows up in logs, etc and someone could potential hijack it.

2) The session expires after a set period of inactivity (usually 30 or 60 minutes.)

3) No, IP addresses are not considered.

4) It depends on server configuration and whether cookies are allowed on the client.
 
Sreyan Chakravarty
Ranch Hand
Posts: 65
Firefox Browser MyEclipse IDE Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeanne Boyarsky wrote:1) No. Cookies are stored on the client (if you use them.) Sessions are stored on the server. They can be referenced by a cookie or parameter (JSESSIONID.) It is better not to use the parameter because then the session id shows up in logs, etc and someone could potential hijack it.

Where in the server is it stored ? I mean does the server maintain a Map or Hashtable of all sessions created ?
Also I have seen that each request generates a session-id. Now I am not talking about login into a page or anything, just a simple "Hello World" servlet will generate a JSESSIONID which remains same if I request the web-page from the same browser. How does the web-server remember the browser and PC so that it can generate the same session-id ? How does it map a session-id to a request? I mean if IP is not considered.

If a server creates a session-id or more specifically a session for each request then there will be innumerable sessions created on a real-life webserver right ? Most of them will be unused since the user is not logging in every time. Am I correct ?

I did not understand what you meant by they can be referenced by a cookie parameter. Does every "first-time" request that I make to a server resource generate a cookie ? Because as I have said earlier even a simple "Hello World" servlet will generate a session.

This is what confuses me. If every access generates a session then the server will get overloaded right ?

Jeanne Boyarsky wrote:
3) No, IP addresses are not considered.

Then what is considered ? Because if I print out the JSESSIONID of a servlet that session-id will remain same for all subsequent access to the servlet over the browser.

If you want I will share the code that I am using to print out the session-id each time ?
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65524
105
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sreyan Chakravarty wrote:
Where in the server is it stored ? I mean does the server maintain a Map or Hashtable of all sessions created ?

That is irrelevant. The Servlet API provides the API to manage the session; how the container implements it is immaterial. But conceptually, all of the scopes, including the session scope, are very much like Maps.

How does the web-server remember the browser and PC

That's what the cookie is for.

If a server creates a session-id or more specifically a session for each request

It doesn't.

Most of them will be unused since the user is not logging in every time.

Even though recording login authentication is usually accomplished by storing info in the session, the session actually has nothing at all to do with logging in. It's just one of the four scopes available for storing information in a Java web app.

 
Tim Holloway
Bartender
Posts: 18413
58
Android Eclipse IDE Linux
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sessions. HTTP is a stateless, non-continuous protocol.

In other words, when you're working with HTTP, you do not connect to the server, talk back and forth, then disconnect. Instead, you send a single request to the server, it processes it, and returns a single response. Once that response has been sent, the client and server are disconnected. Want to send another request? The whole cycle repeats. Real-world note: for efficiency reasons, the actual network communications like to use a "keep-alive" connection mechanism, but it's not part of the HTTP design paradigm - you design like keep-alive doesn't exist.

Because HTTP is stateless, but real-world applications often do require state, the concept of the HTTP Session exists. All the HTTP Session is is the application state information relating to one particular client. A client being a single instance of an HTTP client application program. Or simply illustrated, if my desktop computer has IE and FireFox both communicating with the JavaRanch server, that's 2 clients. Regardless of how many windows and tabs they are using. I could have 2 different instances of Firefox connected and they would be 2 clients. IE, of course, doesn't like more than one instance to run, but that's IE's problem.

In order to associate a client's identify with a particular state-set on the server, you need some sort of identity. Hardware MAC addresses won't do it - they cannot be seen outside the local LAN segment. IP addresses won't do it either. Thanks to NAT, all clients coming from my site have the IP address 216.199.14.19. Not simply all clients on my desktop computer, but all local instances. Windows, Linux, tablets, even WiFi phones.

So lacking a reliable third-party identity mechanism, J2EE uses HTTPSessions and jsessionIds. The HTTPSession lives exclusively on the server and its most salient features are the Map mechanism that holds objects stored in Session context and the user's login context - if the user has logged in via Container Security Services. To associate a session with a client (user), the jsessionID serves as a handle (key) to a (presumed) hash map of all server HTTPSession objects. This is an abstract Map - a really heavy-duty server might be paging sessions out in and out of files, databases or other persistent storage - or bouncing it between servers in a cluster, but from the application developer's point of view, it's there when it needs to be.

Since HTTP is stateless, the jsessionid gets passed back-and-forth on each HTTP request/response cycle. If possible, it's in a cookie. If not, the application code should be invoking the URLRewrite mechanism to append it to URL links and form action addresses being sent out so that they will come back in on the URL when the next submit is done.

And here is something very important to know: The jsessionid may NOT be the same value on every request/response cycle. It is not the case that the jsessionid is sent to the client, cached there and re-used on all subsequent requests. The jsessionid is whatever jsessionid was returned from the previous request response. Accept no substitutes. In particular, for security reasons, when you switch to https (secure) transmission, the old jsessionid becomes invalid. A new jsessionid is returned from the secure response. Since the jsessionid is a "random" value with absolutely no information carried in it other than its own value, what the server is basically doing is fetching the HTTPSession from the session map via its old key (jsessionid), generating a new jsessionid, storing the session in the session map under the new key (jsessionid), and removing the old key/value from the map. Actual order and mechanism may vary, but that's the net effect.

So in other words, neither client-side code (javascript or whatever) nor application code should meddle with the jsessionid itself. The client and server simply trade it back and forth automatically - albeit with a little help from URLRewrite if cookies aren't available.

 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!