On 4 April 2011 16:53, Stephan Richter <srich...@cosmos.phy.tufts.edu> wrote:
> On Monday, April 04, 2011, Laurence Rowe wrote:
>> The authenticator is described on
>> http://pypi.python.org/pypi/plone.protect, but basically it adds an
>> HMAC-SHA signed token into the form submission. By validating this you
>> know that the submission came from a form that your site rendered,
>> rather than an opportunistic 'drive-by' attack from another site.
> So why don't we make this a built-in feature then? The token manager (I think
> you call it the authenticator) needs to be smart, since it needs to deal with
> stale tokens and similar issues, but otherwise we could just add an
> authentication mechanism into z3c.form.
> Mmh, if the token gets stored in the session variable, then we do not even
> have to worry about token management, since the session container has already
> that logic.
> I have a feeling I am missing a level of complexity here...

There should be no need to store anything in sessions, it really is as
simple as ensuring that you include a signed token in the form
submission that is separate from the user session identifier (as
cookies get posted automatically on any form submission.)

>> I'm happy to go with (3). I assume it is not common for z3c.form users
>> to have non-button actions or customize the ButtonActionHandler?
> Not in my experience.

In that case I will attempt to implement it in plone.z3cform first as
that will allow me to just reuse the existing plone.protect stuff. My
only concern really is how easy it will be to disable for individual
forms - as I think it's important to have protection by default. I'm
hoping that the following will work:

* Register a ProtectedButtonActionHandler on z3c.form.form.Form (to be
more specific than the default ButtonActionHandler registered on the
IForm interface.)

* Register the default ButtonActionHandler on a IUnprotectedForm
interface, which individual forms can provide if they need to accept
submissions from other sites.

For a more general z3c.form protection scheme we can then look at
making the zope2 dependencies in plone.protect optional. I would also
like to change the token format of plone.protect to include the issue
time, so secrets do not need to be rotated to invalidate old tokens,
much as plone.session now does:

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope )

Reply via email to