Al Hobbs wrote:Are you sure this isn't your homework? I find it hard to believe you are thinking up all these diverse questions so quickly. Maybe they're from a book or your teacher? FESS UP.
Yes, this is not my home work. I am a working professional and have some experience in J2EE apps . But never thought about it deeply. Now was going through the token authentication so just wondering the difference between cookies and tokens and their internals.
HttpSession is an interface for a server-specific object. It resides on the server and never on the client. The server creates an HttpSession object when the user requests a session with create option or logs in via JEE standard security. The server keeps all HttpSession objects in a Map, although the session data can be serialized in order to pass it to another server (in the case of clustered servers) or written to persistent storage if there's a need to free up RAM. It is this that mandates that all session-scope objects must be Serializable.
The session hash key can be transferred to and from the client in one of 2 ways:
1. As an appendage to a URL. For example, "https://coderanch.com/foo/bar;jsessionid=Aa1234BCDE"
2. As a cookie with name "jsessionid".
Cookies are safer, since if you forget to build a link with jsessionid attached or users type in a raw URL without jsessionid, it's easy to lose contact with the session. However in many parts of the world, cookies cannot be used freely so URL rewriting (to add the jsessionid) is the only other option. And it your client doesn't have cookie support, you have to use URL rewriting.
Java has HTTP APIs that handle cookies automatically, which makes it more convenient to write web client applications using cookies, both jsessionid and user-defined cookies.
The actual value of jsessionid is basically randomly-generated data and its only value is for the server to locate the actual HttpSession in its Map. In fact, the server can and will change jsessionid values without warning for various reasons, so you should never attempt to cache it or work with it directly. Which is the answer to your 4th question. Yes, it's possible to hijack a jsessionid and preventing that from happening while in a secure session is one reason why jsessionid's value can be changed by the server.
An IDE is no substitute for an Intelligent Developer.