Session variables and cookies seem very similar to me. I understand the technical differences, but how do you decide when to use one vs. the other?
+1
A:
Cookies can persist longer than a single session. However, cookies may also be deleted by the user, or you may have a user whose browser does not accept cookies (in which case only a server-side session will work).
danben
2010-02-10 21:43:32
A:
Most of the time, session state is persisted using cookies. So it's not really a question of one or the other, but how to use them together.
Using your framework's session infrastructure may make things easier, but tracking state manually with cookies usually gives you finer grained control. The correct solution depends on what you're trying to accomplish.
Daniel Pryden
2010-02-10 21:45:24
"The correct solution depends on what you're trying to accomplish." I believe that's exactly what the question's trying to get at....
sprugman
2010-02-10 23:01:50
A:
Sessions are stored on the server. If you store something in a cookie, the user's browser sends that information with every request, potentially slowing down your site from the user's perspective. I try to avoid using cookies when I can.
Brandon Montgomery
2010-02-10 21:45:43
But when you're using a session, the server will send a session cookie with every request anyway. I think what you're trying to say is that a minimum of data should be kept in cookies, since all the cookie data will need to be sent across the network on each HTTP request and response.
Daniel Pryden
2010-02-10 21:47:36
A:
Cookies are sent to the server on every request, so if you plan to store a fair amount of data, store it in session, otherwise if you are storing small amounts of data, a cookie will be fine. Any sensitive data should be stored in session, as cookies are not 100% secure. An advantage of cookies is that you can save memory on your server that would normally be storing session data.
JonoW
2010-02-10 21:47:08
+6
A:
Sessions are stored on the server, which means clients do not have access to the information you store about them. Session data, being stored on your server, does not need to be transmitted in full with each page; clients just need to send an ID and the data is loaded from the server.
On the other hand, Cookies are stored on the client. They can be made durable for a long time and would allow you to work more smoothly when you have a cluster of web servers. However unlike Sessions, data stored in Cookies is transmitted in full with each page request.
Daniel Vassallo
2010-02-10 21:47:23
@Ben, not always true, PHP uses files to persist sessions and are therefore resistant to a restart (as is a db store). Generally you only loose session data when they are persisted in memory and or you are using an application server Glassfish etc.
Byron Whitlock
2010-02-10 21:58:02
@Ben: Technically you can have persistent sessions as well. You can have sessions stored in a databased, or on the filesystem, for example. In fact some applications require persistent sessions to keep audit trails of who had access to the application resources.
Daniel Vassallo
2010-02-10 21:58:06
definitely not for all servers, many servers persist session data on disk, in DB, etc.
StasM
2010-02-10 21:58:11
@Ben, ...if session is stored on the web server directly. If you're using a SQL server or state machine to store session (thinking IIS/ASP.NET), it will survive a restart of the web server.
bryanjonker
2010-02-10 21:58:53
@all. Fair points. I must have been working on wonky php servers in the past :)
Ben
2010-02-10 22:03:15
In fairness, most implementations of "session" will require cookie support so the server can associate client with session. There are cookieless implementations that add extra data to querystrings but generally they are the exception.
spender
2010-02-10 22:09:28
@Byron You can overwrite the PHP session handler to create your own Session handler. On popular method is to store sessions in the DB when dealing with clustered servers
MANCHUCK
2010-02-11 02:22:25
A:
Cookies are client-side, sessions are server-side. Use cookies for small pieces of data that you can trust the user with (like font settings, site theme, etc.) and for opaque IDs for server-side data (such as session ID). Expect that these data can be lost at any time and they can not be trusted (i.e. need to be sanitized). Use session data for bigger data chunks (for many systems can store objects, data structures, etc.) and ones you have to trust - like authorization status, etc. In general, use session data for storing larger state data.
You can store things like authorization status in cookies too, if it's needed for GUI, caching, etc. - but never trust it and never rely on it being present. Cookies are easy to delete and easy to fake. Session data is much harder to fake, since your app controls it.
StasM
2010-02-10 22:02:50
+2
A:
- use session always
- use cookie only if you need longer logged-in sessions - then add a cookie with an encrypted userId.
Bozho
2010-02-10 22:07:26