[Zope-dev] CSRF protection for z3c.form

[Roger]

Hi Laurence, Stephan 

> Betreff: Re: [Zope-dev] CSRF protection for z3c.form
> 
> On Wednesday, April 06, 2011, Laurence Rowe wrote:
> >    def update(self):
> >        super(Form, self).update()
> >        self.updateActions()
> >        self.authenticateSubmission()
> >        self.actions.execute()
> >        if self.refreshActions:
> >            self.updateActions()
> > 
> >    def authenticateSubmission(self):
> >        if self.actions.executedActions:
> >            authenticators = zope.component.getAdapters(
> >                    (self, self.request, self.getContent()),
> >                    interfaces.ISubmissionAuthenticator)
> >            for authenticator in authenticators:
> >                authenticator.authenticate()
> > 
> > This would allow for multiple authenticators to be 
> registered as named 
> > adapters, for instance PostOnly, CheckAuthenticationToken, 
> > CheckCaptcha.

btw,
PostOnly and the condition check "if self.actions.executedActions:"
is probably the same. Because if executedActions is False it must
be a GET request. right?

 
> I like this in combination with Rgoer's ignoreProtection, 
> which should be false by default, because we want to make 
> forms secure by default.
> 
> It would be great, if we would ship with one non-trivial 
> authenticator and I would love to see an add-on package 
> providing CheckCaptcha. :-)

Now it becomes interesting to me and I like it more and more,
let me take a closer look and discuss some details...

concept naming,
if we use an "ignoreProtection" marker let's rename 
the method authenticateSubmission to updateProtection
which also reflects that the method is apart of the 
form/update method stack. And let's rename the 
ISubmissionAuthenticator part to smomething like
IFormProtector or so. I do not like the word
authentication in this concept. Authoriastion
whould probably also make sense at least if captcha
is involved which is authorization and not authentication. 


captcha,
CheckCaptcha sounds very interesting and raises some questions
to me.

I guess if a captcha doesn't fit we need to abort processing
actions and return ASAP the plain form again with another
captcha.

first question,
I looks to me that the concept is heavy related to the 
action conditions. What about if each form action has it's
own for protection check?

a simple example:

- cancel button is allowed without a check
  (this really will hurt if not possible)

- form submit is not allowed without a check


second question,
should we be able to return something if the updateProtection
failes. Probably the updateProtection method should return True/False
and if False is returned hookup another method call which could
return content ASAP (probably not possible in update stack).
Or should we set a marker called like we do in AddForm 
with _finishedAdd?

third question,
I guess we should take a closer look to the action condition.
It looks to me like we should implement the check closer
to the form action condition concept. E.g. an action condition
defines if an action get rendered and another new action
argument could be called checker. Such a checker method could
then check if an action can get executed or not.
This whould defently require a marker flag because an action
can also not return content. Or we should use a plain python
error handling if a checker fails?

sidenote, such a checker argument could also be used independent
from the page token concept.

btw,
I still do not understand how the full concept will work.
Where is the hook/method which will setup a token?


What do you think?


Regards
Roger Ineichen


> Regards,
> Stephan
> -- 
> 
> Entrepreneur and Software Geek
> Google me. "Zope Stephan Richter"
>