Re: Different sessions, same client

From: Date: Mon, 24 Jan 2011 15:49:16 +0000
Subject: Re: Different sessions, same client
References: 1 2 3 4  Groups: php.general 
Request: Send a blank email to php-general+get-311001@lists.php.net to get a copy of this message
[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.. 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

« previous php.general (#311001) next »