Tabbed browsing and sessions

[Peter Chant]

Am I right in assuming that when I connect from one browser, using several
tabs to a database produced in mysql/php/apache only uses one session for
all tabs? I have been loosing records from my database and my best guess
is that each tab is not a separate session, therefore the session variables
are shared by all tabs and unfortunately this plays havoc when I try to
update my database using the forms I have created.

Is there anyway to force each tab to have a separate session, if that is my
problem? My application was written not realising this potential problem
and I am a bit stumped on how to fix it. At least I am the only user so I
know not to break it.

:-(

Pete
--
http://www.petezilla.co.uk

[Daniel Tryba]

Peter Chant <pe**@petezilla.co.uk> wrote:

Is there anyway to force each tab to have a separate session,
No. Tabs are nothing special in anyway to the server.
if that is my problem?
No, the problem is that your application isn't "thread safe".
My application was written not realising this potential problem and I
am a bit stumped on how to fix it.

Don't use the session to store variables in a "global scope". You
mentioned forms, so you could generate random IDs per form and use that
to store the sessionvars for that form:
$_SESSION['formid_foo']['foo']='foo';
$_SESSION['formid_bar']['foo']='bar';

[Alvaro G Vicario]

*** Peter Chant wrote/escribió (Thu, 21 Apr 2005 01:14:18 +0100):

Am I right in assuming that when I connect from one browser, using several
tabs to a database produced in mysql/php/apache only uses one session for
all tabs?
As you know, browsers do not use sessions, they merely send session IDs to
server, typically using cookies. The browser will send the cookie if
instructed to do so. If the cookie is set to be deleted when browsing
session ends, I believe you need to (al least) close all open browser
windows. So I'd say tabs are not the problem.
I have been loosing records from my database and my best guess
is that each tab is not a separate session, therefore the session variables
are shared by all tabs and unfortunately this plays havoc when I try to
update my database using the forms I have created.

Session variables are for values that must be shared among pages. Yours
seems to be the opposite case: values must *not* be shared. Why use
sessions then? Anyway, if they're strictly necessary I guess you can create
a session with a random name and store that name in the form itself.
Something like:

if($_POST['session_name']!=''){
session_name($_POST['session_name']);
session_start();
}else{
// Create new session or display error, whatever
}

My code probably won't work, but I hope it gives you an idea.
--
-- Álvaro G. Vicario - Burgos, Spain
-- http://bits.demogracia.com - Mi sitio sobre programación web
-- Don't e-mail me your questions, post them to the group
--

[Samuel Caparrós]

I have currently the same problem, if I got you right that is. I
designed a athentication/session system and now I find out that when I
open different instances of the same browser (hitting New Tab in
Firefox or File - New - Window in IE, as opposite of double-clicking
the desktop IE icon again) the navigation window duplicates, and both
windows now are in the same page, use the same session and therefore
the same session vars, hence messing everything up when navigating
simultaneously.

Still looking for a solution :|

[Peter Chant]

Alvaro G Vicario wrote:

As you know, browsers do not use sessions, they merely send session IDs to
server, typically using cookies. The browser will send the cookie if
instructed to do so. If the cookie is set to be deleted when browsing
session ends, I believe you need to (al least) close all open browser
windows. So I'd say tabs are not the problem.
Well, I have left various browsers open on various desktops. I first became
aware when using a tabbed browser. I think the problem is if I have two
copies of my 'edit member' form open, one for Tom and the other for Dick.
If they both exist in the same session and I use one variable to store the
persons ID, $cont_id I have good chance of overwriting Tom's data with
Dick's and vice versa.

Session variables are for values that must be shared among pages. Yours
seems to be the opposite case: values must *not* be shared. Why use
sessions then?
Well, I thought that sessions were 'A Good Thing (TM)'?

I should have just stck to post data.

Anyway, if they're strictly necessary I guess you can
create a session with a random name and store that name in the form
itself. Something like:

if($_POST['session_name']!=''){
session_name($_POST['session_name']);
session_start();
}else{
// Create new session or display error, whatever
}

My code probably won't work, but I hope it gives you an idea.

Hmm, kind of see where you are coming from, not quite sure putting the
session name is quite the right plan.

It looks like when I submit a form I need to include in the form, not the
session variables, the id of the database record that the particular form
relates to.


--
http://www.petezilla.co.uk

[Peter Chant]

Samuel Caparrós wrote:

I have currently the same problem, if I got you right that is. I
designed a athentication/session system and now I find out that when I
open different instances of the same browser (hitting New Tab in
Firefox or File - New - Window in IE, as opposite of double-clicking
the desktop IE icon again) the navigation window duplicates, and both
windows now are in the same page, use the same session and therefore
the same session vars, hence messing everything up when navigating
simultaneously.

Still looking for a solution :|

Hmm,

if I'd known perhaps it would have been easier to not use sessions, or
limited them to storing which style sheet I wanted to uses for the pages.
Though I can see some advantage in using the same session with multiple
pages if each were separate we would both not be in this mess.
--
http://www.petezilla.co.uk

[Peter Chant]

Daniel Tryba wrote:

Peter Chant <pe**@petezilla.co.uk> wrote:

Is there anyway to force each tab to have a separate session,
No. Tabs are nothing special in anyway to the server.

if that is my problem?

No, the problem is that your application isn't "thread safe".

! I did not know what that meant until know, learning the hard way.

My application was written not realising this potential problem and I
am a bit stumped on how to fix it.

Don't use the session to store variables in a "global scope". You
mentioned forms, so you could generate random IDs per form and use that
to store the sessionvars for that form:
$_SESSION['formid_foo']['foo']='foo';
$_SESSION['formid_bar']['foo']='bar';

Eek. You seem to suggest re-inventing sessions again to create
'sub-sessions' for each form!

I assume I would have to pass the random id as post (get?!) data or a hidden
form field (I can't remember the name of the appropriate tag). It might be
just as easy to pass the variable in question, $cont_id since only I use
this app so people fiddling with the variable is not a problem.

It looks like this multiple tabs thing really takes away a lot of the
advantages of sessions in PHP.

--
http://www.petezilla.co.uk

[Good Man]

"Samuel Caparrós" <le*********@gmail.com> wrote in
news:11**********************@z14g2000cwz.googlegr oups.com:

Still looking for a solution :|

use different web-browsers at the same time. that way you can double-check
your css too.

[Tony Marston]

"Samuel Caparrós" <le*********@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

I have currently the same problem, if I got you right that is. I
designed a athentication/session system and now I find out that when I
open different instances of the same browser (hitting New Tab in
Firefox or File - New - Window in IE, as opposite of double-clicking
the desktop IE icon again) the navigation window duplicates, and both
windows now are in the same page, use the same session and therefore
the same session vars, hence messing everything up when navigating
simultaneously.

Still looking for a solution :|

I came across this very same problem some while ago, and it took quite some
time to figure out a solution. The biggest problem is that "new tab" or
"new" does not actually open up a new browser instance, it merely creates a
clone of the current instance. This clone includes browser history as well
as the session name, and it is the session name which provides the session
id which is used to link with session data on the server. My solution is as
follows:

1) Completely new instances, not clones, can only be created by avoiding the
"new tab" and "new" options. The user must start a completely new browser
instance from scratch.
2) The application must use a session name which is different to the default
PHPSESSID. In my application I use "menuNN" where "NN" is an
auto-incrementing number. As the relationship between session names and
session id's is one-to-one, the only way to have multiple sessions id's in
use at the same time is to have multiple session names.
3) The user must start the application at the logon screen, as it is only
the logon process which can choose a new session name. The session id is
allocated automatically. In my logon process I scan to see which session
names are currently in use, then allocate a new one by incrementing the "NN"
value. The session name thus generated must therefore be included in all
URLs, otherwise the link to a specific set of session data will be lost.

Tricky, but it works.

--
Tony Marston

http://www.tonymarston.net

[Samuel Caparrós]

Tony Marston wrote:

1) Completely new instances, not clones, can only be created by avoiding the "new tab" and "new" options. The user must start a completely new browser instance from scratch.

Of course :) That solves the problem, but still I have to either

1) convince the customer to not use "clones" under any circumstances to
navigate simultaneously, but creating new browser windows for that (my
current system works fine with this).
2) make sure the customer will get an error if creating a "clone" (this
would be ideal, but that's where I'm lost).

I've been thinking of creating a txt dummy file on server, named after
the SID, that each page would open and keep open. Then a Javascript
would close it before page transition. The next page would check wether
the file is in use or not, and return an error if so.

I'll try today and see what I can get. But I can already foresee the
first problem; popup windows or Right Click - Open in new window would
give problems. And these are more common than your average "New Tab"
user, as far as I can see.

[defaultuserbr]

Samuel Caparrós wrote:

Tony Marston wrote:

1) Completely new instances, not clones, can only be created by avoiding the

"new tab" and "new" options. The user must start a completely new

browser

instance from scratch.

Of course :) That solves the problem, but still I have to either

1) convince the customer to not use "clones" under any circumstances

to navigate simultaneously, but creating new browser windows for that (my current system works fine with this).
2) make sure the customer will get an error if creating a "clone" (this would be ideal, but that's where I'm lost).

I've been thinking of creating a txt dummy file on server, named after the SID, that each page would open and keep open. Then a Javascript
would close it before page transition. The next page would check wether the file is in use or not, and return an error if so.

I'll try today and see what I can get. But I can already foresee the
first problem; popup windows or Right Click - Open in new window would give problems. And these are more common than your average "New Tab"
user, as far as I can see.

I'd have to say that as a user, I'd be pretty irritated if you did
figure out something. When I'm on site, lots of the links there I'm
going to open in a new tab. This saves me time, because when I'm done
there I just close that tab and the original page is still there. Also,
if I like what I see in that tab, I can keep it around for future use,
while I continue to explore other stuff.

Were I to encounter new requests for login each time, I'd pretty
quickly bail on your site and go to one much more user friendly.
There's little or no good reason that I can see for what you are
proposing.

Brian

[Samuel Caparrós]

A pretty simple one; it's not simply a website, it's a corporate
application that will probably handle loads of important data.

[Peter Chant]

Samuel Caparrós wrote:

A pretty probablyne; it's not simply a website, it's a corporate
application that will probably handle loads of important data.

Mine application is not corporate, probally only ever I will use it but the
security of the data is far more important than having to log on separately
for each tab.

That said, being as we can't force MySQL to do that the point is fairly
moot. I think I will just create tempoary id variables to tie each form to
the correct variables.
Pete

--
http://www.petezilla.co.uk

[R. Rajesh Jeba Anbiah]

de***********@yahoo.com wrote:

Samuel Caparrós wrote:

Tony Marston wrote:

<snip> I'd have to say that as a user, I'd be pretty irritated if you did
figure out something. When I'm on site, lots of the links there I'm
going to open in a new tab. This saves me time, because when I'm done
there I just close that tab and the original page is still there. Also, if I like what I see in that tab, I can keep it around for future use, while I continue to explore other stuff.

Were I to encounter new requests for login each time, I'd pretty
quickly bail on your site and go to one much more user friendly.
There's little or no good reason that I can see for what you are
proposing.

I strongly agree with you. When the web application is designed, it
has to be designed with concurrency in mind. Instead, avoiding
concurrency and hence user friendliness is a stupid and costly mistakes
of any designs. If I'm right, the recent internal changes in Yahoo!
email somewhat tries to avoid concurrency--but it is totally
annoying--every time I open a new tab in FF, it redirects to main page
but flagging that message as read. Guess, Yahoo! lacks good
programmers.

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/

[Geoff Berrow]

I noticed that Message-ID:
<11**********************@z14g2000cwz.googlegroups .com> from R. Rajesh
Jeba Anbiah contained the following:

Guess, Yahoo! lacks good
programmers.

I think they have at least one...
--
Geoff Berrow (put thecat out to email)
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/

[R. Rajesh Jeba Anbiah]

Geoff Berrow wrote:

I noticed that Message-ID:
<11**********************@z14g2000cwz.googlegroups .com> from R. Rajesh Jeba Anbiah contained the following:

Guess, Yahoo! lacks good
programmers.

I think they have at least one...

I think, that guy is also gone. The recent "accessibility" change in
<http://www.yahoo.com/> proves that. Being a loyal Yahoo! for some
years, I've also mailed my (decent) feedback on their changes on
Y!groups. What I understand is that they're just trying to copy
Google--the recent Y!360 invitation model --pretty same like Gmail and
the CSS based design (internal CSS?!) of 360--again same like blogger
is showing a copycat work. Sounds like it is dying.

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/

[Geoff Berrow]

I noticed that Message-ID:
<11**********************@o13g2000cwo.googlegroups .com> from R. Rajesh
Jeba Anbiah contained the following:

I think they have at least one...

I think, that guy is also gone

http://lerdorf.com/bio.php

'..He is currently an infrastructure engineer at Yahoo! Inc. in
Sunnyvale, California. '
--
Geoff Berrow (put thecat out to email)
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/

[R. Rajesh Jeba Anbiah]

Geoff Berrow wrote:

I noticed that Message-ID:
<11**********************@o13g2000cwo.googlegroups .com> from R. Rajesh Jeba Anbiah contained the following:

I think they have at least one...

I think, that guy is also gone

http://lerdorf.com/bio.php

'..He is currently an infrastructure engineer at Yahoo! Inc. in
Sunnyvale, California. '

I don't think, he is doing "everything" there or allowed to do so.
FWIW, <http://blog.outer-court.com/archive/2005-03-03-n69.html>

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/