Limiting user to one open form

[CaseyR]

First, a little context.    This exercise is an attempt to remediate the data integrity issue that occurs because the session queue is shared by all the open tabs of a browser.

My workaround is to add a session value such as EntityTypeAlreadyOpen when the user opens a form to add a new record or edit an existing one for an entity type.  This session value is deleted when the user clicks Save or Cancel.    If the user tries to open the form again in the current browser tab or any other before the session value has been deleted with Save or Cancel,  they get an alert explaining the problem and directing them to log out and in again if they want to open this entity type form.   This check is done in the PRE routines and ans is set to 0 if the check fails.    Here is where the problem occurs.  The intent is to send the user 'back' to the calling page.  How do I do that?

That's my approach, but I would be more than happy to hear of better ways to limit the user to one open form for an entity type, or better yet a way to deal directly with the session values shared between browser tabs.

Many thanks.   

[Stu]

Hey there Casey,

This is an issue I've been mulling over for some time also.

Because we can be really militant about the browser used in our system I'm thinking a Chrome Extension will be the best way to handle this for us. So instead of having to worry about adding the code into our server, we rely on the browser to make sure only one instance of our system is open at any one time.

We've had a lot of trouble with people have two tabs open, and overwriting records .. NOOOO.

And this is the best solution I've come up with (it's not "best" as in good, but best of what came to mind). Make a browser extension to do the work (I've looked at what's out there, and there doesn't seem to be an existing one that allows for this functionality, although that might have changed since last look).

[Bruce]

Hi Casey,

>> This session value is deleted when the user clicks Save or Cancel.

unfortunately this is insufficient. what happens if the person simply navigates away using the URL bar? Or back button (in the case of page mode?) or presses Esc on the keyboard (in popup mode)? Or a bunch of other IF's.

The whole multiple-tab thing is a problem I'm trying to solve in NT7, but at this stage the effort is imcomplete, and I've yet to determine if it will actually be completed successfully. I have high hopes though.

Cheers
Bruce

[CaseyR]

Thanks, Stu.

Good to know I am not alone.  Alas, I have no control over the browsers my users may use with my app. 

[CaseyR]

Hi, Bruce

Yeah, I thought of users going off without clicking Save or Cancel.  I decided that since they would have ignored instructions to Save or Cancel before going on, well, they could put up with the inconvenience of having to log in again.  Better that than have their data compromised.

As you know, shared sessions in tabs are a common problem for web apps in general.   I ran into this item that was proposed as a partial solution:
https://github.com/chrisdew/subsession/blob/master/README.md

But it still leaves me with the original workaround question,  what is the best way to 'return' a user to the calling page if a form procedure fails a check on opening?

Thanks.
 

[Stu]

One thing I've been thinking about - it's not a solution - is to have a little "alert" div which polls the server every x seconds/minutes.

In here you can tell the user whatever you want .. BUT in this situation you could tell them whether you have detected that there are TWO tabs open.

I imagine (haven't tested) that you could work some jquery magic in that div and get it to even MODAL itself into a little alert form.

[Bruce]

>> But it still leaves me with the original workaround question,  what is the best way to 'return' a user to the calling page if a form procedure fails a check on opening?

Are your forms in Page Mode or Popup mode Casey?

cheers
Bruce

[CaseyR]

Hi, Bruce

I am using page mode for now, but I can see pop up mode occurring some time.

Thanks.

[Bruce]

yeah, and the approach for the two (to answer your root question) is quite different.

Personally I think you're better off hanging on for NT7 - at least in the short term until we know if it will definitely work or not.

Cheers
Bruce

[CaseyR]

No question an internal NT solution would be much better.   I still have a few months to go on my major app, so hopefully NT7 (with solution) will be available then.

On the minimal probability you haven't considered this approach, how about  SessionID created from two parts?  One part is stored as a browser session cookie and the other is passed by URL like it used to be up to late NT4.  Complications and work for all to be sure, but it does provide both the security of a cookie based ID and the unique workflow/data integrity of a URL id. 

[Bruce]

>> Complications and work for all to be sure,

yes you're not kidding! And I don't mind the work so much, but the complications are non-trivial.

For example;

The server stores the "state" of a form in the session queue. Since forms are not recursive even if a form is abandoned this results in minimal overhead, and the space is re-used when the user returns to that form. However if multiple forms are now allowed, then the server has to store multiple "states", which is ok, except that if a form is abandoned it won't get around to cleaning out that state until the session ends.

There are other complications, but hopefully I can find solutions.

cheers
Bruce