I am reading on a book and it is talking about session and cookie. While session is everything within the session scope for requests coming from the same client, and it can carry session attributes which holds the attributes in time as specified by session.setMaxInactiveInterval(). While Cookie on the other hand, is used for doing a similar thing for carrying name/value (String) pairs, and it also has its own cookie.setMaxAge() method for determining its time to live on client's machine. But ... I am just confused The book is saying that Cookie is for supporting session. But how are they related? If the session expires, does the Cookie expire? and vice versa?
Cookies are a general mechanism for retaining data associated with a web site on the client. Sessions are a server-side mechanism. The only relation between them is that a cookie is used to record the session id so that the same session can be "hooked up" for each request.
Cookie is used for recording the session id in name value pairs which is created by the server and is send back to the client.This server only creates the cookie object and sends it to the client.By the session we can create uniterrupted request-response conversation with the aid of cookie.
keep trying...thats the way to success...<br />with best regards...<br />p.agarwal
HTTP is a stateless protocol, so each Request from the User has no history in it. But sometimes information needs to be passed from one page to the next.
On the server side we can use a Session object to store all that information a single user might need, but how can we associate a session a user makes in one request with a different request from the same user? The answer is Cookies. A Cookie can be set by the server to provide a unique ID to the server side session. Then each time the user makes a request that Cookie is sent along with the request providing the ID for the session to use. So the Cookie is a means of combining a Client side state with the Server side state through an otherwise stateless protocol.
So a couple of related questions you had. The session has a time out mechanism, and a Cookie has a different time out mechanism. Why both mechanisms? Generally speaking only the server-side timeout will have an effect. Normally the Max-Age of a client side session tracking cookie is left at 0, which means it expires when the user closes the browser. If the user leaves his browser open but is inactive for longer than the server's session time out, the server makes a new session and puts the new session id in the Cookie. If the user closes the browser (therefore losing his session tracking Cookie) then tries to go back to the same application, the server has to make a new Session and the old one is left to time out on its own.
You also asked why have both Cookies and Sessions when they both basically do the same thing? There are a couple of reasons: --> Sometimes the data in a session needs to be kept secure. Passing cookies over the internet is not secure, so that information should be kept on the Server, which means the Session.
--> Second, there can only be one NAME=VALUE pair per cookie, so if you have a lot of information to maintain, transporting it across the internet with each request can take a while (and lends itself to be tampered with by Proxies) and retrieving a particular Cookie value in a large list is not particularly efficient. In this case it may also be better to store the information in the Session.
--> Finally, Cookies only hold String values so if you wanted to maintain any other data type it requires more work to manipulate from String -> required type. Sessions store any Object type which makes things easier.
This question ask many times, i get results when i search cookie. As questioner Chun Lee confuse between cookie & session, i also confuse.But reading some notes, white papers, links & pdf, i think my confusion removed(only about fundamentals of httpcookie & session). As sheriff & author Bear Bibeault writes, i thinks its useful for short ( interview question) answer. As Steve Luke answered very nicely. His one line attracted me
Sometimes the data in a session needs to be kept secure. Passing cookies over the internet is not secure, so that information should be kept on the Server, which means the Session.
Its absolutely true because cookie have many drawbacks(read this). But is session secure perfectly? When i search session drawbacks i got this book. Can knowledgeable person tell me on which we trust( as cookies have lots of drawbacks it lost trust)? That book created in 30/Nov/2004, so i think by the time, that situation also change! I confuse again! [ July 29, 2008: Message edited by: Mandar Khire ]
Millions saw the apple fall, but Newton asked why.
If you understand, say "understand". If you don't understand, say "don't understand". But if you understand and say "don't understand". How do I understand that you understand? Understand!
My opinion is the session is safer, even if being able to generate legitimate session ids were easier than described in the paper because:
1) Having a legitimate session id doesn't do anything. the session id would have to be for an ACTIVE session. 2) Having the id of an ACTIVE session doesn't get you much closer to getting important information. The server has to decide to provide you that secure information. Since, as was said, you shouldn't be sending this information out, then how can the attacker get it?
This doesn't mean that you can be lazy with your sessions, a high-jacker may still be able to steal someones session and perform actions on the server which you would not want them to be able to do. These types of transactions are usually performed using HTTPS, with secondary notifications, like email confirmations, and are hidden behind URLs that are very hard for the client to discover.