RE: Different sessions, same client

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> From: Steve Staples [mailto:sstaples@xxxxxxxx]
> Sent: Monday, January 24, 2011 6:31 AM
> To: Tommy Pham
> Cc: 'Paul M Foster'; php-general@xxxxxxxxxxxxx
> Subject: RE:  Different sessions, same client
> 
> On Sun, 2011-01-23 at 17:40 -0800, Tommy Pham wrote:
> > > -----Original Message-----
> > > From: Tommy Pham [mailto:tommyhp2@xxxxxxxxx]
> > > Sent: Sunday, January 23, 2011 5:23 PM
> > > To: 'Paul M Foster'
> > > Cc: 'php-general@xxxxxxxxxxxxx'; 'Thijs Lensselink'
> > > Subject: RE:  Different sessions, same client
> > >
> > > > -----Original Message-----
> > > > From: Thijs Lensselink [mailto:dev@xxxxxxxx]
> > > > Sent: Sunday, January 23, 2011 12:21 AM
> > > > To: php-general@xxxxxxxxxxxxx
> > > > Subject: Re:  Different sessions, same client
> > > >
> > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > Hash: SHA1
> > > >
> > > > On 01/23/2011 07:33 AM, Paul M Foster wrote:
> > > > > 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 and good. My problem, however, is that I have multiple
> > > > > applications in different tabs running on the same server, which
> > > > > may all use the same sub-variables, like "username". As a
> > > > > result, they run into
> > > > each other.
> > > > > One application will think I'm logged in when I'm not logged in
> > > > > to that application, but to another in the same browser on the same
> box.
> > > > >
> > > > > So my question is how to prevent this using the standard PHP
> > > > > functions relating to sessions. I'd like different applications
> > > > > in different tabs on the same box/browser to have different
> > > > > sessions, so they don't share data.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > Paul
> > > > >
> > > >
> > > >
> > > > Using session_name will allow you to run two different sessions in
> > > > the same browser.
> > > >
> > > > session_name('app1');
> > > > session_start();
> > >
> > > Paul,
> > >
> > > I'd would go with session_name($_SERVER['SCRIPT_NAME']) or
> > > session_name(substr($_SERVER['SCRIPT_NAME'], 0,
> > > strripos($_SERVER['SCRIPT_NAME'], '/')).  My regex skills sucks so I
> > > can't give you a sample using regex.  But you get the idea.
> > >
> > > It's easier to get a particular app's relevant data to the URL while
> > > not hard coding the session name, eventually giving your app(s) more
> > > flexibility especially if you may have multiple URLs mapped to an
> > > app serving different purposes/clients.
> > >
> > > Regards,
> > > Tommy
> >
> > Forgot to mention that this assumes your app's design is MVC like with a
> single point entry only.
> >
> >
> 
> Hey guys...
> 
> I too once tried this, basically so that I could stop users logging in on
> multiple tabs, and if they did, then it would kill the previous login (or not
> allow them to be logged in as they would be logged in still).  I had so many
> issues, that I abandoned it.
> 
> After reading this thread, I thought I would try Tommy's suggestion about
> using a unique named session... so I just tried this:
> 
> <?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...

Steve,

The problem with uniqid() is it's based on unix timestamp, IIRC.  So the session name always changes and it's impossible to figure out what's the previous session name is so how could you get the previously saved session data.  That's why I suggested the session name based on URL/URI.  If the app does not have a MVC like desgin, you could use a particular parameter's value to ensure that session name is valid for certain purpose.  For example:

http://server/training/schedules/ is different from http://server/events/schedules/.  

Should the person in charge of both needs to maintain them, it still could be done getting the session_name based on the url requesting.  Thus, you'd be able to get the previously saved session data.  Also, if the need arises, you could also get data from different sessions if the business needs requires it because you know exactly what the session name based URL is.  As in the example above, the maintainer could check to ensure that the certain scheduled items wouldn't conflict each other in cases where the attendees are required to attend both :)

Regards,
Tommy





-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux