Persistent variables and multiple browser instances

PaulCook

Hi all,

This is a question of best practice -- ie. this is a problem which any serious website must have overcome, but about which I can find very little on the web. So I'd like to hear about some solutions people have used!

Most articles about achieving persistent variables (ie. that last from one request to the next) mention hidden variables and session variables. However, few mention the implications of the fact that users can be using multiple webbrowser instances.

There seem to me to be three types of persistent variables in a complicated application:

1) Simple page-specific variables, such as whether a list of items is expanded or not. Hidden form variables are ideal here.

2) Variables that describe a user, and are constant for an entire session, such as username, password, etc. Normal session variables are ideal here.

3) THE TRICKY ONES:
Variables which are, well, variable, but which are security sensitive and/or long, and so shouldn't really be appearing in hidden variables. For example, database primary key values for records that are being edited.

The problem comes when a user uses multiple instances of a browser, or the back button a lot. Then if these are stored as simple session variables, one could very easily land up using the incorrect primary key (eg from browser instance A) to UPDATE data submitted from, say instance B.

The only way I can see out of this is to send with each page request a random, unique key (not unlike a session id), which refers to a PART of the session. Then variables of type 2 are normal session variables, and type 3 are put into this unique part of the session, which is flushed and re-created with each request.

Is this really the best method???

Thanks,
Paul

sfullman

Paul, this seems to be your first post. YOu sound experienced in some ways, I'll pass on some suggestions.

In IE, if click the little blue "E" on my computer, that's a thread of IE. If that page uses session_start() to start a session, then great. If I hit control-N (new window), that page also has the session.

Be advised though, that if I click the blue "E" again, I'm opening a new thread of IE -- this means that this window, windows spawned from it, DO NOT have the same session key. for example, if the user is logged in on one browser, and open IE as a nother process, in that process they're logged out.

My new policy in submitting form data is to post the form data to a hidden iframe. If there's a problem, the iframe uses javascript to talk to the parent, writing error messages via innerHTML, OR alert() method whatever. That way you never get "page expired" showing.

I'm dealing with the same thing on multiple pages. You pretty much HAVE to pass a unique key for each window since this is invisible to the server. So popups or new windows should have a url like newwindow.php?windowKey=4839483 where the number is generated. But you can't set this in session, since again session vars are by nature available to all pages.

FINAL NOTE: Your form posts should be self contained, including the primary key. You should be able to submit something from pageA and then pageB respectively with ALL the info to create the UPDATE .. where myID = thisvalue statement -- if not you're doing some bad coding.

By the way, if you're very good in JS you can disable Control-N and control that process yourself.

Sam Fullman
Compass Point Media

PaulCook

Thanks for some very useful comments! Some questions/replies:

I would tend to think that any attempt to control the spawning of new browsers either sharing or not sharing the session data (via JS) is destined to blow up in one's face -- especially for users of anything other than IE. Still, thanks for pointing out that not all instances share the session (cookie). What a mess, generally!

About point (2): an intriguing idea! Two questions: doesn't using frames lead to problems with bookmarks, search engines, etc., geting the frameset rather than the content? How do you avoid those problems? Then, I presume that the hidden frame is responsible for sending the main frame to a new page should the submitted data be succesfully validated?

Lastly, your comment on containing enough data in form posts to recreate everything for SQL queries: what is the problem with storing primary keys, etc, in session data, obviously with unique page ids used? I'm just worried that putting things like primary keys client-side might potentially enable malicious users to run "custom queries" by submitting requests with arbitrary primary keys.

Thanks a ton for your comment!

sfullman

about the iframes, you might give it a try:

then your form action is action="formaction"

This gives you an invisible place to post the form without refreshing the page. Then using javascript, suppose you wanted to change a piece of data upon sucessful update, you'd just come back with:

window.parent.document.all.someLocation.innerHTML='<?php echo new value here;?>'

that way you don't need to refresh the whole page for people with slow connections. If you need to refresh the page, have the called page in the iframe come back with

window.parent.location='blah blah'

As far as primary key, if it's the primary key of a RECORD, I can't see having that in session. If it's the primary key of the USER, that's different; you should (unless you can show me why nobody else does this but ought to) only have a single user logged in at once. So you don't need multiple "primary keys" for that.

I have a lot of data-editing applications which is removed from the user directly. storing this in session is impractical.

I also wouldn't worry about hacking since session vars are stored on the server.

Let me know if you apply the iframe idea, I eventually will post some of these concepts for those who are interested.

Best,
Sam