> I know this topic has been talked about a LOT but all the info >I've managed to get from google is that there is no center / best option >to choose between using sessions or cookies.
You're comparing apples and oranges -- cookies are one of the mechanisms by which PHP implements sessions. The other is URL-munging. So if you use sessions, odds are cookies are coming along for the ride. What you definitely /don't/ want to do is to store application data in the cookie itself, due to various security (public machines) and technical (4k size limit) concerns. PHP's built-in session support uses the cookie data as an identifier, to match a user to the data stored in a session file, and in general this is the way to go. The only major flaw I've found with PHP's session support is that it doesn't appear to be possible to force the data to be written without also closing the session. In general, PHP's session features are pretty complete, and easily modifiable. To clear up a few items below: >Cons of Sessions >1. saves it in /tmp - world viewable not necessarily so, see php.net/session_save_path >2. Session ID may be easy to guess unless I md5 the sessionID before >sending it out you can define your own session id if you'd like, see php.net/session_id for example, to help deter session fixation, you might require that the session be a hash of certain environment variables, such as remote IP or user-agent string. >Cons of cookies >1. cookies can be rejected by users >2. if rejected, means session can't be preserved across pages?? (this I'm >not sure) this is where URL-munging will come into play; PHP will resort to this if cookies are rejected. >3. cookie is stored in user's hard drive. What is user using public PC? don't use the cookie to store application data - use it to determine the user's identity. This is the behavior that PHP's session features encapsulate. --------------------------------------------------------------------- michal migurski- contact info and pgp key: sf/ca http://mike.teczno.com/contact.html -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
