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*********@gm ail.com> wrote in
news:11******** **************@ z14g2000cwz.goo glegroups.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*********@gm ail.com> wrote in message
news:11******** **************@ z14g2000cwz.goo glegroups.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.