Yes it will be only ajax calls and I will not be using SQLFORM. I am presuming this is the mechanism you use for preventing CSRF attacks -
1) Generate a unique value for every form that is sent to clientside. 2) Assign this value to _formkey, and also store it in the session. 3) When the user submits the form back compare the value in the _formkey and the session. 4) If the value matches then its a valid request, otherwise its an attack. If you are using the above mechanism - 1) How do you know which formkey to compare to which key in the session. As you have generated multiple form keys and stored them in session, one for each form. I was thinking of this scheme for CSRF protection - 1) Generate a CSRF protection token and set it on client side during the first request. 2) On every subsequent ajax call the client will grab the token and post it with the data. (client side double submit) 3) The server will compare the returned cookie value with the POST request, to verify if it is a valid request. Thanks, Murtaza On Wed, Jul 18, 2012 at 6:03 AM, Massimo Di Pierro < [email protected]> wrote: > It is possible. Yet there is some overhead because SQLFROM is built on top > of helpers. It will create a representation of the form even if it unused. > It may work to create a SQLFORM light that only does what you need. It can > be done in a few lines of code. Let me think about it.... > > > On Tuesday, 17 July 2012 18:12:48 UTC-5, Anthony wrote: >> >> I don't think there are any SQLFORMs. It's all custom Ajax calls. I'm >>> guessing your JavaScript library (angular, in this case) needs to take care >>> of it? >> >> >> Presumably you could still use SQLFORM to generate the _formkey value, >> send it to the client, and have the client send it back with the form >> submission. This doesn't require using web2py's default form serialization >> in the view. It's probably only worth doing it this way if you are using >> SQLFORM on the server side for processing. >> >> Anthony >> > -- > > > > --
