Hi Mike,
based on what you're saying, I gather that if I were to choose to
use cookies, and if cookies were rejected by the user, PHP will default to
using sessions?
----: quote :---
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.
----: End Quote :----
Is the above a serious flaw which I need to be aware of?
Thanks
Cheers,
Mun Heng, Ow
H/M Engineering
Western Digital M'sia
DID : 03-7870 5168
-----Original Message-----
From: Mike Migurski [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 11:47 AM
To: Ow Mun Heng
Cc: [EMAIL PROTECTED]
Subject: Re: [PHP] Session vs Cookie Issues
> 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
