Session variables and multiple windows (yet again, eh?)

I know, I’ve read some posts about this, but I didn’t really get a good answer.

Let me get specific. If I have several PHP programs that each have to go to a page that {DOES SOMETHING} and then return to the page who called, the only way I can figure out how to do that is to pass the xyz.php name of the page who called. Then save it in a session variable.

Then after multiple posts in the same page, it grabs the session variable and returns to the original caller.

(That’s just one example of saving things in a session variable. I know I could use HTTP_REFERER, but this is about session variables, not how to call another page and return)

Now what happens if multiple windows are open, and the same programs are running in the various windows, and the same session variable is used in the multiple windows? Won’t that screw things up royally?

Any ideas on how to prevent that?

Actually, I have a number of session variables I use, and if multiple windows are open using the same program pages, WHEW!

How to avoid this?



The easy solution would be to use the database and create some sort of sessionvars table to store session data for users. Each “window” in your application would then access that database for the session data.

The question you have to ask yourself before you do this, however, is: Why are there multiple windows open, and are they necessary for my application?

I personally hate having multiple windows open, and have grown to dislike links opening in a new window or tab within the same application very much. Most of the time when unusual problems like this crop up in applications you have to step back and ask yourself if you are doing things the way you should be. Now may be that time for you. Without knowing your specific situation it’s hard to say, but by the time you search for a solution, nail it down, and then implement it, it may have been easier just to do it a different, more efficient way that would inherently be free of the types of problems you are experiencing.

Your problem is actually quite common, although many web dev. ignore it and just goes for session state storage. Which - as you realize - is a suboptimal solution, especially if your customers are likely to open multiple windows (or if you use iframes).

Since you mentionened multiple posts you may store the reference field in a hidden field of the form - or you may generate the form so that the parameter continues to be part of the action url.

@Czaries: You don’t get to control whether your customers open multiple windows. The likelyhood of them doing so has increased significantly with the popularization of tabbed browsing.

You might want to use local cookie instead of session if you want to allow concurrent access by different windows that do different things.

Cookies are shared by all windows, making cookies unreliable for concurrent access.

Give each of your windows a unique id, and then from within that window, from the point of view of the actual script it’s self, use that id;

$_SESSION['Window_ID']['Variable'] = ...

If therefore, the data stored under a windows unique identity, is to be shared from the main window once the child window has been closed, then use a top level layer which sits on top of those under it, that manipulate the SESSION for a given child window…

$_SESSION // top layer
+ --- $_SESSION['Window_ID_1'] // child layer
+ --- $_SESSION['Window_ID_2'] // child layer
... etc ...

The class for a child layer would be reusable since the reference for the top layer is by it’s own id and nothing more. Not too difficult really…

> …have to step back and ask yourself if you are doing things the way you should be.


I too do not use child windows where I can however the issue is really about the inconvienence of a page load, isn’t it? Well, you will find that now with AJAX frameworks in common use, there is no need for those child windows…

Any changes to be made can now be designed to act upon a specific part of the page without the reload issue, and at the same time, still retain the information on that given page in the meantime.

Isn’t AJAX wonderful huh?

I don’t like applications, which force me to use multiple windows either, but I certainly use the feature a lot myself.

Web applications should, as far possible, be build to allow this. More generally speaking, web applications should transfer application state to the client. The way to do this, is to pass the data with each request, normally in a hidden field, or in the URL. honeymonster already mentioned this, but I thought I would just emphasize that this is the proper solution.

Indeed, creating dataspaces for the different windows will have to do the trick. But what if one window is opened 2-3 times, they will have the same window ID. May be if a window is opened, it should not be allowed to open a new window.

According to me the sessions are to store only unchangeable for all the session (i.e username), or globally chageable variables (that need to be checked and changed on every page i.e. last activity time)

I was obviously talking about the application itself forcing new windows or smaller javascript popup windows. Your reference to tabbed browsing is a non-issue, because session is maintained across multiple tabs during the same browser session - I have done it many times myself.

If you have multiple windows open, and your application relies on server side state, some of your windows may be stale. This is true whether you opened those windows yourself (tabs) or the application did it for you (popups).

You could generate a unique window ID when the window is opened. That would require JavaScript, of course.

In general, there seem to be two ways to avoid problems with updates in concurrent windows when using session data.

  • Dr. Livingston’s idea, keeping data in session using window IDs
  • Keeping data in session using unique IDs for the objects being edited, as mentioned in the PRG discussion.