Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

sessions spanning multiple browsers...

Status
Not open for further replies.

shadedecho

Programmer
Joined
Oct 4, 2002
Messages
336
Location
US
Ok, i have a page that when loaded in a browser window starts a php session using session_start(). Then, it goes about it's business of creating the page. One of the links on the page launches a new browser window (using target="_new") and loads another page. The session is automatically spanned over to the new browser window.

In that second window, there's a function (actually, where the user clicks "Logout") that calls a session_destroy() for that second browser. However, I need that second window to have its OWN session, not the same one as from the first window, so that when the second window's session is _destroy()'d, the first window's session is not touched. I've tried in the second window's page code to set the session_name() to something else, or to change the session_id.. but all that does is replace the name or id information in that session, it doesn't seem to force a start of a new session.

Anyone know what I can do?
 
Well... first things first... as you diagnose your problem test on several browsers. I -believe- this issue has more to do with the client than the server. If I remember right, IE and Mozilla Firebird handle this differently... one of them in the way you want it to actually. Also don't overlook how it performs in tabbed browsing, they're getting more popular in my estimation... though not enough to be a major concern as of yet.

Are the actions distinctly separate? Could you use different parts of the session array and just UNSET the proper one? Or is this a recursive operation disallowing that option?

That would get my vote though... most of my logout/restart the session operations actually just UNSET the SESSION array rather than actually destroying it. More of a fine tooth control.

-Rob
 
the second window that is launched is a highly sensistive login-based application, with private employee information, so the security guy in me says, kill the session when they are done. The first window is another application that they have logged into previously, but its information is not nearly as "sensitive", so the goal is actually to allow them EITHER to open a browser and go the sensitive application and login, or to go to the non-sensitive application, login, then click the link which launches the sensitive application and pushed the authentication through, so they don't have to login again.

As far as scaling is concerned (since there may be other applications in the future which might similarly launch the sensitive application) I think its important that the session in the second window be totally destroyed when they log out of it, rather than just having all its variables unset. But, logging out of the second one should not kill the first window's session, thereby logging them out of that one too.

These are intranet applications, and are being deployed only on IE5/6 browsers. We are on (the dinosaur) 4.0.6 version of PHP for the moment (though I haven't found this behavior to be listed as a BUG that's been fixed yet).

Surely there is a way to tell PHP, "never mind the current session, let's start a whole new one". am i wrong?
 
Well yes, but then it does that for the whole session. Not just your current window, in my experience... that's the clients issue... some view multiple windows as multiple instances of the program, and some view multiple windows as multiple windows in the same instance... I think it may even matter if it's relaunched or a "pop-up".

I would break up the $_SESSION[] array to
$_SESSION['GENERAL'][];
and
$_SESSION['SENSITIVE'][];

I understand what you're saying about the security, but I'm not sure that's an issue... perhaps someone else can speak to that.

If it is, then don't use UNSET and just do
$_SESSION['SENSITIVE'] = array();

Which will cause the information to be overwritten on the harddrive with a blank, surely as secure as session_destroy();

-Rob

 
i just can't accept the premise that PHP does not have a way to tell itself "USE A BRAND NEW SESSION", regardless of how the script is launched or what it gets from the browser. there should be some way to tell it a new ID and/or NAME and it create a new session file on the server.

btw, in my current testing, I tried in the first part of the script that executes for window 2, to just say session_id("blah") and set it to something OBVIOUSLY different from what the default id would be in window 1. immediately after that call, i do session_start(). In that page, for reference, I print out the session_id(), and it is indeed "blah".

Then, before "logging out" of window 2 and destroy()'ing the session, i go over to window 1, and click refresh, and it logs out, as if the session no longer was recognized by it. So the session is live in window "B" but dead in original window "A". Then, I click refresh on the window "A", and it immediately "logs back in" but this time it grabs the session information from window "B", and its session_id is now "blah" as well. what's up with that?
 
It may very well be that PHP only recognizes one session variable set per browser. This does not seem unreasonable to me. The two browsers also use a common pool of cookie data, so what is available to one should be available to the other.

Either use skiflyer's very good advice, or create your own session management using setcookie().

Want the best answers? Ask the best questions: TANSTAAFL!
 
That all sounds like reasonable behavior to me... not exactly the best behavior... but I imagine if you tested in mozilla you'd get that ;).

Here's why I suggest you should accept the premise...

If the browser isn't differentiating completely between the two windows, how do you expect the server to? If the browser is differentiating completely between the two windows, how do you expect the server not to?

This is a client side issue, IE handles it in a way you don't like... you can try other browsers, or use another method... but you can't expect the server to differentiate based on windows on your desktop.

-Rob
 
skiflyer - I understand your reasoning.

actually, through a rather heated and convoluted fashion, I found an answer to my problem. If you're interested in how PHP's bug support system reacted to me reporting this to them (it's NOT pretty, not reading for the faint of heart), check out this link at


In any case, for posterity, I'll tell ya what ended up fixing my problem.

I tried individually to, in window "B"s script, change the session_id() and also the session_name(). Neither of the changes alone fixed my problem. But, when I in that second window change both the session_id() and the session_name(), it works fine.

Here's the quirk to understand (as I understand it anyway). PHP has a config in its .ini file which specifies the default session_name for each session. Since its the default globally (PHPSESSID), if you don't choose to change that session_name in a session, you will get every one of your sessions sharing the same name.

Each browser instance (including all its child instances - ie, pop-ups) gets assigned one unique ID that creates the unique session_id (32 character MD5? hash of something, I assume).

So, in cases where you don't specify a unique/different session name for your script to use, it will use PHPSESSID (the global default). When you open up manually seperate instances of the browser, they each get their own session_id. So, their sessions stay seperate even though they use the same session_name. When you spawn a window though (like a popup), you automatically inherit the session_id from your opener, so if you don't specify a new session_name to use, you will be using the same session_id and session_name pair, which means it will get stored in the same session file!

So, to sum it all up, the quirk is that to uniquely identify your new session, especially if its from a pop-up/child window, specify a new session_id AND session_name. Do this right before your session_start() call.

session_name("blah");
session_id("blahsession");
session_start();

Basically you only need to specify the new session_id for each new child instance once, in the first script that opens in the child window. (each script after that will by default get the newly set session id) You can of course specify it over and over if you want, as long as you specify the SAME session_id over and over.

Keep in mind though that (according to the php documentation AND my experience) if you change the session_name, that is not persistent, so you will have to specify that same session_name in EVERY script that opens in the new child window.

So, the first page has:

session_name("blah");
session_id("blahsession");
session_start();

and each other page in that child instance should just have:

session_name("blah");
session_start();

I employed this in my application and it works beautifully. Hope this helps someone else!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top