+1 for implementing convenient CSRF.
I wonder if you could make your implementation more orthogonal by
implementing a CSRF "field/widget", and make your `protected` attribute
simply trigger the inclusion of this field implicitly.
This way you wouldn't need to change the `*pageform.pt` templates like you
do now, and `setupToken()`/`checkToken()` would move to the widget code.
On Wed, Sep 18, 2013 at 11:41 AM, Jan-Wijbrand Kolman <janwijbr...@gmail.com
> I've been working on CSRF protection for zope.formlib.
> I have a "csrfprotection" branch in my zope.formlib fork on github. The
> changes against the current zope.formlib mainline can be found here:
> When creating form components based on zope.formlib.form.FormBase, one can
> enable this protection just by setting the attribute ``protected`` to True
> on the component.
> This implementation is based on the following assumptions:
> * We do not want to keep server-side state(!)
> * An "attacker" that attempts CSRF cannot get to information stored in
> cookies that are meant for the domain of the (forged) request.
> * The token stored in the cookie is sufficiently random and long, to be
> practically "unguessable" by the attacker.
> * The form submit is deemed valid as long as the token in the cookie is
> identical to a hidden input value that is part of the form submit.
> My questions:
> * Do you find this feature useful enough to be, in principle, included in
> * I'd like to kindly request someone to review my branch and provide
> The included test cases describe a few more questions and concerns about
> this implementation.
> Thank you in advance!
> kind regards, jw
> Zope-Dev maillist - Zope-Dev@zope.org
> ** No cross posts or HTML encoding! **
> (Related lists -
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -