This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes Servlets and the fly likes Use of Cookie Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Servlets
Bookmark "Use of Cookie" Watch "Use of Cookie" New topic
Author

Use of Cookie

Felix Li
Ranch Hand

Joined: Jul 09, 2008
Posts: 38
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?

Thanks in advance.


FL<br /> <br />SCJP,SCWCD
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60741
    
  65

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.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Felix Li
Ranch Hand

Joined: Jul 09, 2008
Posts: 38
Thanks a lot, sheriff Bear!
Agarwal Priyanka
Greenhorn

Joined: Jul 25, 2008
Posts: 20
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
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4164
    
  21

Again, just to add to the info already posted...

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.


Steve
Felix Li
Ranch Hand

Joined: Jul 09, 2008
Posts: 38
A very detailed explanation, thanks!!!
Mandar Khire
Ranch Hand

Joined: Sep 11, 2007
Posts: 492

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.
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4164
    
  21

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.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Use of Cookie
 
Similar Threads
Cookie and activex reports
Confusion between Cookie and JSession
session.invalidate() invalid?
Is session object thread safe.
Chapter 6(Session Management) notes (HFSJ) for revision