> -----Original Message-----
> From: Donovan Brooke [mailto:li...@euca.us]
> Sent: Monday, January 24, 2011 7:49 AM
> Cc: php-general@lists.php.net
> Subject: Re: [PHP] 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

Reply via email to