Re: [PHP] Session vs Cookie Issues
If anyone can help shed any light on the sort of instability I'm seeing, that would really help. Apache child processes die right and left, with segfaults and bus errors. Hardware? Overly agressive optimization switches when you compiled? Using pre-release software somewhere in the chain? -- Joel Rees, programmer, Kansai Systems Group Altech Corporation (Alpsgiken), Osaka, Japan http://www.alpsgiken.co.jp -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Session vs Cookie Issues
On Wed, 2 Jul 2003, Matt MacLeod wrote: I've had similar issues using cookies. The cookie was storing my details but only for the duration of the session despite having set the expiry date to a time well into the future. Any ideas for why this may have happened? Someone rm'ing /tmp/ for example. -- Mika Tuupola http://www.appelsiini.net/~tuupola/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Session vs Cookie Issues
I've had similar issues using cookies. The cookie was storing my details but only for the duration of the session despite having set the expiry date to a time well into the future. Any ideas for why this may have happened? 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. Mike - can you expand on your point above? Thanks, Matt -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Session vs Cookie Issues
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? If you chose to use sessions, and cookies were rejected by the user, then PHP would append the session ID to each internal link, in order to preserve the session ID between requests. If you just used cookies with no supplemental method, and cookies were rejected by the user, then your method would break. - michal migurski- contact info and pgp key: sf/cahttp://mike.teczno.com/contact.html -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Session vs Cookie Issues
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. Mike - can you expand on your point above? I've running into this problem where--in an app with a lot of OOP and reference-passing, on a shared host--requests would die out before reaching the end, though they'd do enough work to be useful. I can't seem to be able to fix the instability (see below), but I was able to work around one of the flaws of the session support: normally the user's session data is read from a file, typically in /tmp, at the start of a request. This data is manipulated by the script when values in $GLOBALS['_SESSION'] are changed, and then it's written back to the file at the end of the request. My issue was that frequently, my scripts wouldn't finish correctly, session data would not be written to the file, and therefore it would be lost between requests. I had hoped to find a function like session_write_close() that did not have the side effect of closing the session altogether, but instead I ended up rolling my own, with more frequent disk writes at crucial junctures. If anyone can help shed any light on the sort of instability I'm seeing, that would really help. Apache child processes die right and left, with segfaults and bus errors. - michal migurski- contact info and pgp key: sf/cahttp://mike.teczno.com/contact.html -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
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/cahttp://mike.teczno.com/contact.html -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Session vs Cookie Issues
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/cahttp://mike.teczno.com/contact.html -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
