The book is incorrect. There is no problem with multiple forms per page with one caveat.
If two or more of the form are SQLFORM.factory forms or if they are SQLFORMs related to the same table, you must give each of them unique names. Massimo On Dec 28, 9:44 pm, Fabiano <[email protected]> wrote: > Hi, > > I just read a paragraph on the book that really worried me, on Chapter 7, > Section Forms and Validators / FORM / Multiple forms per page: > > It reads "(...) when multiple forms are present on the same page, the > mechanism for preventing double submission breaks, and you must omit the > session argument when calling the accepts method. (...)". > > This really disturbed me because the way I see, the main benefit of this > mechanism is not to prevent double form submission but to prevent CSRF > attacks, which is a very important feature these days. Prevent CSRF attacks > per se is a complex subject [1] to just let it on each developers hand, > specially when the framework in use already has good prevention mechanism. > > What also bothered me was that, considering the importance of this matter, I > could not see any technical reason to this mechanism not work with multiple > forms or be broken by it. So, before look at web2py code, I decide to test > it first. > > Doing what the book recommends, omitting the session when call accepts(), > has the obvious effect of disabling the mechanism, just pressing F5 after a > submission makes a new submission. > > Then, I tried to put the session argument back to see how would it break > before dive in to the code. And I had a very pleasant surprise, it didn't! > It worked flawlessly, with each form having a different formkey. > > I guess this was fixed after that book section was written. If so, it may > look just an outdated information, but I see it as security issue also, as > any one that follows its recommendation may end with a vulnerable > application, without need, with an important security feature just disabled. > > [1]http://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_... > > Regards,
