Sessions again -- Oh No !

[Anon]

Just when I thought it was safe to go back in the water (and leave hidden variables behind -- for the most part) comes this little gem out of Meloni's Book, "PHP, Fast & Easy" (p. 271)

"The PHP parser gets the value of $PHPSESSID from the user cookie."

HUH ???

Does this mean if the user has disabled cookies for their browser, that sessions will not work on their local machine?

Say it isn't so, Julie!

[brandonschnell]

yep.

check to see if the user has cookie support before sending them to a php sessions page.

cookies store user specific data on a client machine. the data is not secure and its only realistic to store a couple of bits of data there.

sessions store user specific data on the server. the data is secure (user can't directly modify it besides what your scripts allow). however more information can be stored (such as serialized php objects).

in order for php to find the right session to use it needs the session id. this can be stored either in cookies or as part of the url. those are about the only two ways to connect a specific user with a specific session thats universally supported.

since the session id "space" can be immense, the chance is low of a user stumbling onto another users session by modifing their session id (editing the cookies or the session id in the url).

[zalath]

Correct, but sessions don't necessarily need to exist over several connections - personally I use them for storing user authentication information, so as far as I'm concerned, if the user disconnects, s/he can feel free to log in again 😉

Hence passing the PHPSESSID as a part of the url works for me, and probably most other cases as well.

(Note: if PHP is compiled with --enable-trans-sid, the programmer needn't worry about passing the id, PHP will do it automagically)

-L-