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
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 tickets, so I've put together what I consider to be
the conclusio
32 matches
Mail list logo
