NetTalk Central
NetTalk Web Server => Web Server - Ask For Help => Topic started by: CaseyR on October 09, 2013, 01:11:07 PM
-
Hi, Bruce
About a year ago, we started a discussion of the data integrity problem of multiple tabs or browser instances sharing the same session queue:
http://www.nettalkcentral.com/index.php?option=com_smf&Itemid=36&topic=3980.msg14893#msg14893
With NT7 released, you demo'd for ClarionLive a solution that addressed the problem for Browse procedures but mentioned that dealing with Forms was a lot more complicated. I haven't noticed anything in the release notes, but wondered if a solution to the issue with forms has been developed.
While having the usual crisp NT solution to the issue would be great, I am quite willing to work around the problem by forcing the users to explicitly Save or Cancel a non view only form or be logged off the next time they try to open the same form. I can use a SessionValue to determine if the form was properly saved or cancelled last time and can alert the user to the issue, but I am having trouble forcing the log out. I tried changing the RequestReferer to host (with 'http://') and index page with '?Logout_btn=yes' appended then exiting the Pre or the Init routines with Ans = 0.
What is the best way to force the user to log in again?
Thanks
-
If your forms require the user to be logged in have you tried just setting this property and letting nettalk handle the re-direction? p_web.SetSessionLoggedIn(0)
-
>> but wondered if a solution to the issue with forms has been developed.
no, not yet.
>> or be logged off the next time they try to open the same form.
logged off is not the same thing as deleting the session. So logging off isn't a solution. Deleting a session might be seen as a solution, except that it doesn't really help. At the root you have potentially multiple tabs open. If two of those tabs are on the same table then it gets icky because the server cannot distinguish between browser-side tabs.
Deleting the session would kill the formstate of the first form, but would also kill the formstate of the second form as well. And this would still have the effect of the form being "open" in the tab which would confuse users.
Cheers
Bruce
-
Thanks, Kevin, that was what I was looking for.
Yes, Bruce, it is not a great solution. Ugly in fact, but the more users users are opening multiple tabs or browser instances the risk of trashing their data set is that much greater. I will work on it some more. I think there is a way to ensure nothing is saved from the compromised form. Thanks.