Difference Between PHP Cookies and PHP Session

Can anyone explain the difference between these two and so explain where it is advised to use what.

 

Cookies are client (browser) and session's are server based.
So a cookie stores the information in the browser for retrieval.
Sessions store the information within the server for retrieval based on PHP's internal system of session instances.

 

Cookies are non-safe - they can be changed and manipulated by the user, and shouldn't be used to keep anything important - they're good for visuals - say if someone choses to not show certain parts of the site, or someone else want to see all the info-boxes on the site, or similar.
Sessions are "safe" - in that they CAN be hijacked and manipulated, but it takes a bit more effort - used for storing more sensitive information, but usually used to store a session-key or some token to acknowledge that the user is logged in (of course it can also be used to store other information, if you want, that are being used on several pages).
Cookies have a limit on length, while sessions don't.

 

Hi.
Each are different entities as elaborated by the 2 gurus before me. For best practice however, both are used (directly / indirectly) and I have my own term for this: cookie-based-session I could be wrong though...

 

Hi my answer is they do same work but they have some diff between theme
for example someone is logging to ur website if you build a session for that user the session is alive till user dont close the browser window if they close for using again from ur website they should login again but with cookies you let user with one login they can use your website without login again in specific time understand?

 

One big thing to remember about sessions is that they typically use a cookie, in most cases called "PHPSESSID". While the information is stored on the server, the cookie is sent to the client. That's how PHP sessions can be hijacked, intercepting that cookie... the "man in the middle" attack being the most common of these. A way to limit the risk is to narrow the window during which that session ID is valid by simply changing the session ID hash every page-load using session_regenerate_id. That way older ID's are invalidated frequently. Smaller window of attack == less risk. You might further want to check the IP address and user-agent strings, while those too can be easily faked it's like door locks on a car, it keeps the honest people out.

One bit thing about cookies is that they are sent on EVERY file request BOTH directions, so the more cookies you use, the more crap that is sent with each file request. It's why when possible I try to rely on just one cookie and store as much as I can on the server. It's also why some people suggest putting static files on a subdomain or other domain that doesn't share cookies with the site, so you can avoid the cookie overhead on files that don't need them. Doing so also means that things like the PHP session ID gets sent back and forth less, which further reduces the odds of it being intercepted.

The biggest difference from an implementation standpoint is that session values are NOT available client-side... so you can't access them from JavaScript. JS can read, set and unset cookies, it has ZERO access to session data other than the random validation hash... which really isn't all that useful client-side.

Another thing to keep in mind is that sessions are typically stored in a database on the server, and in a particularly inefficient fashion given they can contain almost any type of data. As such I usually try to limit the data stored there to the user ID, IP addy and UA string so that the sessions database stays small(ish) -- then pulling data as needed about the user when/if I need it from my own user database. I've seen a LOT of people store a copy of the user info in the session, and when the user count climbs this can QUICKLY have a negative impact on session handling in terms of speed, disk use and memory use.

 

As for storing sessions in a DB, vs just having them stored on disk, what's your opinion on that? I haven't done any real production testing on speed, but I was thinking that if the storage is SSD or SAS, it would be faster to just read from disk? And no need to purge db etc.

 

Uhm... since a DB is usually stored on disk (though you CAN declare them to be memory based) is there even a difference?

Unless you mean flat files -- the default behavior -- in which case advantage DB thanks to INDEXES. You'd be doing a lookup by the hash as the primary key so even a simple self-optimizing binary tree index would blow away flat files -- since you can bet your sweet bippy the filename lookup takes longer than an indexed database, particularly if you are managing hundreds or even thousands of sessions at once.

Though that's the question, are you handling enough sessions at once to warrant switching from the default "everything goes in a directory under /tmp" to the extra code needed to call a database. Generally speaking once you break around 60 sessions at once I've found the database is the better choice.