YAY! it worked!!
so then i tried this:
$_SESSION['t_'. time()] = time();
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
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...
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..
"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:
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
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)
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!
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php