> -----Original Message----- > From: Donovan Brooke [mailto:lists@xxxxxxx] > Sent: Monday, January 24, 2011 7:49 AM > Cc: php-general@xxxxxxxxxxxxx > Subject: Re: Different sessions, same client > > [snip] > > <?php > > session_name(uniqid()); > > session_start(); > > echo session_id(); > > ?> > > > > YAY! it worked!! > > > > so then i tried this: > > <?php > > session_name(uniqid()); > > session_start(); > > $_SESSION['t_'. time()] = time(); > > echo session_id(); > > echo '<pre>'; > > print_r($_SESSION); > > echo '</pre>'; > > ?> > > > > and it doesn't preserve the older session information... so I must be > > doing something wrong. I can assume that because the name is being > > regenerated new each time, that the old "previous" session is > > destroyed (which would make sense) but then how can *I* ensure that > > each session is going to be unique enough, but preserve "old" session > > information too? > > > > I know it has to be possible, as my bank doesn't allow multiple tabs > > while online banking. > > > > /sigh the joys of protecting users from themselves... > > > Hello, > What seems to be missing from this thread is talk about the root of the > problem. You would never want to create the same cookie name for alike > web-apps for the very reason Paul has discovered. Session_name works > because it changes the name of the PHP session cookie. This is important for > CMS builders, Forum builders, or other app builders etc.. > That's exactly part of the 1st point of 3 points I've described in another thread. We don't exactly know the current/future requirements of the business, the different apps being used, who developed those apps, in what way are each app's data need be interconnected/shared, etc. So we can only give suggestions based on limited info disclosure for whatever the reason maybe, perhaps security or something else. Regards, Tommy > Paul mentions: > "Storing any sort of login/auth data in cookies has regularly been panned on > this list. The preference seems to be to store whatever login/auth > information *must* be stored in the $_SESSION variable." > > Well, there are only 2 ways that I know of to retain *state* in a web app (no > matter what web server-side language you are working with), which are > cookies or passing a variable in all links... so I would re-phrase Paul's > statement above to say, to retain state, there is > *always* some reference to login data (whether direct or indirect > (encrypted)), but right, it's not a good idea to store AUTH info. > > Extending Tedd's suggestion, Instead of a unique ID for a session name > (most often session *cookie*), I really prefer a hash of something that > results in a recognizable cookie name over something random. In my > opinion only, it is a bit shady to create a cookie that is unrecognizable. At > the least, when I am managing my own cookies, I will delete "wierd" cookie > names. What I usually do for sessions is create a cookie name that is based > on the domain, and also lists the word "session"... so a format something > like: > > <domain>_session > > A format such as above lets the user know right away where the cookie > comes from and what it does. I would post code, but I haven't written the > hash in PHP yet. > > One last note about this hash, I always include a default to the IP address in > the case of development, or if the site does not have a domain name. > > Oh, and one last last note, Accessing a web app with localhost does not > work well with cookies either.. so in my hash, I redirect those who access > my app from "localhost" to the localhost IP (127.0.0.1) right away. > > I know that last part is a bit complicated, but I help write the hash if the list > is interested. I was really surprised to find no mention of this on the PHP's > examples of sessions. > > Sorry for the long post! > > Donovan > > > > -- > D Brooke > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
