On Tuesday 22 September 2009 21:24:48 Luke Plant wrote:
> 2) Get the view to be exempted from the normal CSRF checks done
> by the middleware. Thankfully, we already have not one but two
> ways of doing this - the manual @csrf_exempt decorator on views,
> and the internal mechanism that allow
On Sep 22, 9:24 pm, Luke Plant wrote:
> > 2. I'm not at all keen on the implementation as a middleware
> > (especially a view middleware, which doesn't play well with generic
> > views and redispatching to other view functions, both patterns I like
> > a lot).
>
> Could you explain a bit more abo
On Tuesday 22 September 2009 12:57:16 Simon Willison wrote:
> The main reason I really like preserving form data is that it means
> CSRF failures are less of a problem, allowing us to be much more
> strict about how they work (setting form tokens to expire after a few
> hours, tying tokens to ind
On Tuesday 22 September 2009 13:12:51 Russell Keith-Magee wrote:
> On Tue, Sep 22, 2009 at 10:34 AM, Luke Plant wrote:
> > I've left most of the code itself under django/contrib/csrf because:
> >
> > 1) backwards compatibility with people importing the middleware
> >means we have to leave dj
On Tue, Sep 22, 2009 at 7:12 AM, Russell Keith-Magee
wrote:
> At this point, I'm convinced, mod the minor things I've flagged.
> However, I'd like to see Jacob and Malcolm chime in before this is
> committed.
I've mostly stayed out of the discussion because I haven't had much
helpful to say that
On Tue, Sep 22, 2009 at 6:57 AM, Simon Willison wrote:
> Yeah, I'd like a builtin shortcut like that - used like this:
> render(request, 'template_name.html', {'foo':bar })
> The biggest problem, for me, is finding a decent name - since
> 'render_to_response' is already taken. Maybe something a
On Tue, Sep 22, 2009 at 10:34 AM, Luke Plant wrote:
>
> OK, you convinced me. I really would rather this wasn't baked in, but given
> the migration issues and the fact that it is security related, I guess I can
> stomach it.
>
> I've updated the patch [1] to move things to builtin functionality.
On Sep 19, 4:56 pm, Russell Keith-Magee
wrote:
> End users should be allowed to be as lazy as they like, but
> their laziness shouldn't open security holes in an app that Django
> ships, since the contrib apps (and admin in particular) are the
> obvious first port of call for any systematic CSRF
OK, you convinced me. I really would rather this wasn't baked in, but given
the migration issues and the fact that it is security related, I guess I can
stomach it.
I've updated the patch [1] to move things to builtin functionality. I also
had to fix some bugs to get the csrf_protect decorat
On Sun, Sep 20, 2009 at 2:57 AM, Luke Plant wrote:
>
> On Saturday 19 September 2009 16:56:52 Russell Keith-Magee wrote:
>
>> On Fri, Sep 18, 2009 at 6:09 AM, Luke Plant wrote:
>> > If the target of a is internal:
>> > * add {% load csrf %} to the template and {% csrf_token %} to the form
>>
On Saturday 19 September 2009 16:56:52 Russell Keith-Magee wrote:
> So - let's have both. A middleware enabled by default protects the
> rest of the views. However, we can also have a view decorator lets us
> protect admin (and other contrib apps) explicitly. If users disable
> the middleware, ad
On Saturday 19 September 2009 16:56:52 Russell Keith-Magee wrote:
> On Fri, Sep 18, 2009 at 6:09 AM, Luke Plant wrote:
> > If the target of a is internal:
> > * add {% load csrf %} to the template and {% csrf_token %} to the form
> > * use RequestContext in the corresponding view.
> >
> >
On Fri, Sep 18, 2009 at 6:09 AM, Luke Plant wrote:
>
> Hi Simon,
>
> OK, here is my response. I hope this doesn't turn into a personal my-code-vs-
> your-code match (especially as most of "my code" is really other people's code
> and ideas :-) but I want to make sure we do this right, as it pote
Hi Simon,
> 1. SafeForm has no dependency on Django's session framework. This is A
> Good Thing as I personally avoid sessions in my projects (no need to
> access state on every request if you can get away with not doing it).
...
> It's a bit more than that - I also want something that works
> in
On Sep 18, 12:09 am, Luke Plant wrote:
> OK, here is my response. I hope this doesn't turn into a personal my-code-vs-
> your-code match (especially as most of "my code" is really other people's code
> and ideas :-) but I want to make sure we do this right, as it potentially has
> big implicatio
On Sep 17, 3:42 pm, Simon Willison wrote:
> All good points - the change in function signature naturally fell out
> of the CSRF work (since the form needs access to the request object in
> both cases) but you've convinced me that it's a step too far - I'll
> see if I can fix that.
I just pushed
Hi Simon,
OK, here is my response. I hope this doesn't turn into a personal my-code-vs-
your-code match (especially as most of "my code" is really other people's code
and ideas :-) but I want to make sure we do this right, as it potentially has
big implications, so the following will be "sleev
All good points - the change in function signature naturally fell out
of the CSRF work (since the form needs access to the request object in
both cases) but you've convinced me that it's a step too far - I'll
see if I can fix that.
Cheers,
Simon
On Sep 17, 2:10 pm, Russell Keith-Magee
wrote:
>
On Thu, Sep 17, 2009 at 3:11 PM, Simon Willison wrote:
>
> On Sep 15, 2:57 pm, Luke Plant wrote:
>> OK, I'll wait and see.
>
> Here's the code: http://github.com/simonw/django-safeform
>
>> * it requires using Django's form system. I've got plenty of views that
>> don't (e.g. anything with a d
On Sep 15, 2:57 pm, Luke Plant wrote:
> OK, I'll wait and see.
Here's the code: http://github.com/simonw/django-safeform
> * it requires using Django's form system. I've got plenty of views that
> don't (e.g. anything with a dynamic number of controls). People not using
> django.Forms are le
On Tuesday 15 September 2009 12:28:51 Russell Keith-Magee wrote:
> The CSRF tag approach you have implemented didn't win a lot of fans
> whenever I described it, and for pretty much the same reasons I have
> expressed previously - too many moving parts, and a little too much
> manual intervention
On Mon, Sep 14, 2009 at 9:05 PM, Luke Plant wrote:
>
> On Monday 31 August 2009 15:26:42 Russell Keith-Magee wrote:
>
>> 3. CSRF is currently a contrib app. Why? CSRF control is the very
>> model of a feature that shouldn't be decoupled from the base
>> framework. If we're aiming to make CSRF su
On Monday 31 August 2009 15:26:42 Russell Keith-Magee wrote:
> 3. CSRF is currently a contrib app. Why? CSRF control is the very
> model of a feature that shouldn't be decoupled from the base
> framework. If we're aiming to make CSRF support like XSS support,
> surely it should be baked into the
On Monday 31 August 2009 15:26:42 Russell Keith-Magee wrote:
> 1. Is there anything we can do to fix the problems with the
> ResponseMiddleware? I know there are problems, but at the core there
> is something really good - it seems a waste to throw it all away.
I just stumbled across a new argu
Hi Russell,
> The difference here is that XSS is mentioned in the template docs,
> not the tutorial. The tutorial is happily XSS safe, and the new
> user is oblivious to this fact. You only really need to hunt down
> documentation about XSS when you start dealing with content that
> needs to brea
On Mon, Aug 31, 2009 at 8:45 PM, Luke Plant wrote:
>
> Thanks for your response Russell:
>
>> I've had a quick look at the patch, and found a few minor cosmetic
>> things. I've also done a lot of reading of the archives to
>> understand why the patch is the way it is. A comprehensive teardown
>> o
I wrote:
> In fact, I've just discovered that there is a view in
> current Django that, if you have the current CSRF protection
> enabled, will leak the CSRF token to an external site -- the
> technical 500 debug view in django/views/debug.py has a POST form
> to dpaste.com. (I'll try to fix that
Thanks for your response Russell:
> I've had a quick look at the patch, and found a few minor cosmetic
> things. I've also done a lot of reading of the archives to
> understand why the patch is the way it is. A comprehensive teardown
> of the patch will take a bit longer, but before I do that tea
On Mon, Aug 3, 2009 at 11:25 PM, Luke Plant wrote:
>
> Hi all,
>
> Some big changes to the CSRF protection nearly got in to Django 1.1,
> but didn't. Since then, more work has been done, overhauling the
> whole thing really. There has been a huge amount of discussion on
> mailing lists and ticke
On Sun, Aug 30, 2009 at 3:10 AM, Luke Plant wrote:
>
> Can I have some feedback on this please?
...
> As far as I'm concerned, this is ready for checkin, except that I
> haven't had *any* recent feedback or thumbs up etc. from the list or
> other core devs.
Apologies, Luke. I had this one flagged
Can I have some feedback on this please?
I've now addressed everything outstanding (tested under HTTPS and
updated the tutorials), and I've included a friendly summary at the
top of http://code.djangoproject.com/wiki/CsrfProtection
For those wanting to see the patch, for once Trac hasn't barfe
31 matches
Mail list logo
