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"