On 6 April 2011 18:43, Roger <d...@projekt01.ch> wrote:
> Hi Laurence
>> Betreff: Re: [Zope-dev] CSRF protection for z3c.form
>> On 4 April 2011 19:16, Roger <d...@projekt01.ch> wrote:
>> > Hi Shane
>> >> -----Ursprüngliche Nachricht-----
>> >> Von: Shane Hathaway [mailto:sh...@hathawaymix.org]
>> >> Gesendet: Montag, 4. April 2011 19:54
>> >> An: d...@projekt01.ch
>> >> Cc: 'Laurence Rowe'; 'zope-dev'; stephan.rich...@gmail.com
>> >> Betreff: Re: [Zope-dev] CSRF protection for z3c.form
>> >> On 04/04/2011 10:22 AM, Roger wrote:
>> >> > Just because you can write login forms with z3c.form this
>> >> package has
>> >> > nothing to do with authentication. That's just a form framework!
>> >> >
>> >> > Authentication is defently not a part of our z3c.form
>> framework and
>> >> > should not become one.
>> >> >
>> >> > Why do you think authentication has something to do with
>> >> the z3c.form
>> >> > library? Did I miss something?
>> >> This thread is using the word authenticate differently than most
>> >> other Zope-related discussions. Here, we are authenticating the
>> >> *form*, not the user. We need to be sure that submitted form data
>> >> was produced by an authentic form.
>> >> Otherwise, a crafty site could cause the user's browser to invoke
>> >> some action in the background.
>> > I know what you mean. As long as this is not implemented in
>> > I'm fine Because I don't belive in this kind of protection
>> since I did
>> > some very fancy stuff with easyxdm.
>> Could you please describe in more detail why you don't
>> believe in this sort of protection? As far as I can see the
>> executed in the context of both documents, so modulo any
>> efficacy of form authenticators.
> I think to protect the form is just a part of a concept.
> user generated content. If an application allows to post
> JS in a blog post or comment etc. it should be possible to
> use easydmx to read and re-use the secure form token.
> (not approved but should work)
> One of my bigger concern is also that such a token will
> break a lot of our tests which whould force us to use
> custom non security token generating form classes.
> I'm fine in general for implement such a concept
> in z3c.form but it should be optional.
> Why not offer additional form classes or a mixin
> for support such token?
I intend to make it pluggable, either using an existing plug point or
creating a new one.
I think it's important that this can be easily retrofitted to all
z3c.form based forms on a site, so I don't want to have to rely on all
forms (which may come from other add-ons) needing to inherit from a
particular base class.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -