pombreda / formalchemy

Automatically exported from code.google.com/p/formalchemy
MIT License
0 stars 0 forks source link

[enhancement] a field of "security" type #62

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
info:

http://en.wikipedia.org/wiki/Cross-site_request_forgery

Most modern applications use a CSRF prevention mechanism that involves a
form with additional field with random generated token that is changing on
every request, the form gets validated only when the tokens from form and
POST match eachother.

Original issue reported on code.google.com by ergo14@gmail.com on 9 Feb 2009 at 9:23

GoogleCodeExporter commented 9 years ago
There are two important facets here:

 - FA does not generate <form> tags, so it's easy to add extra elements to what FA
generates
 - There is no cross-framework way to prevent CSRF; you basically need access to the
framework's session

So, the answer is, use whatever CSRF protection your framework gives you when 
you add
the <form> tags.  If you do this a lot, consider subclassing FieldSet/Grid.  (I 
would
consider accepting subclasses that do this for render/validate in the ext 
package.)

Original comment by jbel...@gmail.com on 9 Feb 2009 at 1:54

GoogleCodeExporter commented 9 years ago
yes, you are correct, but i was thinking about doing this in a way where for 
example
using pylons we would archieve uniform way of showing validation errors etc.

Original comment by ergo14@gmail.com on 9 Feb 2009 at 5:30

GoogleCodeExporter commented 9 years ago
it's very easy to add an entry to the _errors dictionary to make it render like 
other
validation errors from your own controller.  and if you are subclassing just 
add it
to your validate method.

Original comment by jbel...@gmail.com on 9 Feb 2009 at 5:41

GoogleCodeExporter commented 9 years ago
great, thank you

Original comment by ergo14@gmail.com on 9 Feb 2009 at 5:43