Workaround for multple browser instance data integrity problem

[CaseyR]

Hi,

The data intedrity problem caused by multiple browser tab or window instances using the same form has been a big concern of mine for quite awhile. 

I thought of a possible work around using HTML5 local storage.  When a local storage variable (maybe even session variable) is saved on a page, it triggers a storage event that can be captured by all the other tabs or windows but not by the orginating instance.  In essence, a message to the other instances.  If a vulnerable form initiates a local storage value on starting and continously listens for the local storage event, the first instance can generate an alert on its page when a second instance opens the same form. In addition to alerting the user,  the first instance can do another local storage action that the second instance captures to trigger its own alert.

This link has a discussion and demo of passing notification between instances:  http://html5doctor.com/storing-data-the-simple-html5-way-and-a-few-tricks-you-might-not-have-known/


Before trying to figure out the code and placement,  are there any significant issues that get in the way?  Any tips on the script or placement in a NT embed?

Thanks 

[kevin plummer]

Thanks for the link. A couple of interesting points.

1) Local means that it’s persistent, and session is simply that the data is lost when the session ends

2) It’s also worth noting that a session is tied to a single browser window or tab

3) Storage is different from cookies in that it’s not shared with the server

I wonder if the NT session ID was created by the browser and then passed to the cookie if that would work? As you moved Tabs the sessionid of the cookie would change?

[Bruce]

Hi Casey,

This has been a concern of mine too, but alas I've never found a solution which actually works enough to be reliable. So my first inclination on reading your post was that it's going to ultimately have a flaw. finding a way to keep data "in the tab", and yet expose it to the server with every request, has always been a problem

However I've done some experimentation here, and I _think_ it actually might be a solution. I've done some basic checking and it seems to me that the sessionStorage approach might actually work. There are some edge cases I still need to explore but it looks do'able.

If it does work there won't be a need for you to do anything - it'll be built-in, and that will be cool! watch this space...

cheers
Bruce
 

[CaseyR]

That's great, Bruce.

Even if the session/local storage is not available to the server in the end, just the ability to force the browser to alert the user to the problem is a huge step up.

[JohanR]

Hi Bruce


Not sure if this is related, but to try and ensure that a session variable is unique to an instance of a form, I prepend the record id to the label.
eg.
  p_web.SSV(clip(record_id) & 'loc:item_description' , 'special widget x 3')

This will create a local variable in the session queue specific for the record id and will make sure that it's not clashing with another record.
If the user opens the form twice for the same record then there could be a problem.

I have not encountered a problem either way yet, but my apps are still quite young and their usage is still very low.


Johan

[kevin plummer]

Hi Johan,

how do you clear your session variable? If I have 2 Tabs open, one on a form (so the session variable is primed) and close that "Tab", then on the original Tab I try to open that form, wouldn't I get the warning the form is already open?

[Bruce]

>> Not sure if this is related, but to try and ensure that a session variable is unique to an instance of a form, I prepend the record id to the label.

this is a very narrow fix, and won't solve the generic problem, except in very narrow situations.

cheers
Bruce