On Monday, June 4, 2012 4:36:34 PM UTC-4, Anthony wrote: > > Massimo pointed out a flaw in my solution in that it would create an >> ever-growing number of session variables and would be vulnerable to a DoS >> attack. >> > > Maybe by default it could cycle through a small number of formnames (e.g., > _formname = _formname + '_1', etc.). So, for any given base _formname, > there could be up to, say, 5 distinct formnames in the session, which would > allow the user to open a handful of browser windows and be able to submit > from any of them. > > Anthony > I had considered something similar to this. It reduces the probability that a users gets a invalid form, but it's still possible.
What I see happening with users and my app is this:. The default page has a form on it, one that is frequently used for entering customers into the system. At some point the user opens a page in a new window. They use this window to do various activities including entering any number of new customers using the form on the default page. At some point they close the window. The original window is now their 'active' window. They enter a new customer with the original form. It fails because the session formkey is no longer valid. In general, a form failing isn't the end of the world. The user can just re-enter the data and submit it. It would be nice if I could give them some feed back. However, with the particular default form I am using, they require asking customers for their personal information, address, phone, etc. When the form fails, they have to ask again which does not make customers happy. So in this case, I'd like to do what I can to make it work every time. It should be noted, my app is used internally and several people may share a computer at a counter. Often they open multiple browser windows and tabs in order to not disturb the browser left by another person.
