Re: A word about CSRF Protection and AJAX
On Feb 25, 9:49 am, Luke Plant wrote: > Sorry, I forgot to continue this conversation. > > I'm quite happy to entertain the idea that the CSRF middleware should > always set the CSRF cookie, but would like to know what other devs > think. > > The main consequence I can think of is this: > > If a page has 'Vary: Cookie' sent in the headers, and was not previously > sending cookies, the new cookie being sent will cause different cache > behaviour i.e. it won't be cached internally in Django or in other > caches. > > This is a significant enough performance consideration to make me > hesitate, but Jonas' arguments about ease of use for people using AJAX > are also significant. > > If we change it, do we want to change it before the 1.3 release? And > backport it to 1.2.X? > > Luke When we upgraded 4 of our Django sites to 1.2.5, we ended up having to write/include a trivial middleware that went something like this: from django.middleware.csrf import get_token class CsrfCookieUsedMiddleware(object): """ Simple middleware that ensures Django's CSRF middleware will always include the CSRF cookie on outgoing responses. """ def process_request(self, request): get_token(request) We needed that because we CSRF protect our logout link on all authenticated pages (using jQuery to submit a POST when you click the link, if no JS then you get taken to a logout page with a logout form). We also have feedback links on lots of pages that we don't render forms for if you have javascript enabled, instead it opens in a lightbox and submits an AJAX post. The problem with that simple middleware or changing Django to always include the cookie is we do NOT want that behavior on any view decorated as CSRF exempt. For example, we have a site that has both the site code and its RESTful APIs running out of the same Django project, so there we had to modify that 'always include the CSRF cookie' middleware because we didn't want that cookie coming back in any API responses, just the website responses. Just figured I'd throw our use cases out there... -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Ticket 14261 - add basic clickjacking protection to Django
See approved ticket: http://code.djangoproject.com/ticket/14261 There, Luke Plant said: """ +1, I was going to suggest it myself. The patch looks pretty good. After Django 1.3 is out, we should have some discussion on django-devs about: - what the default value should be (I think SAMEORIGIN would make it better for general use, with very little decrease in security). - whether we can avoid a new setting - whether the middleware should be on by default or in the project template. """ I already changed the patch to default to SAMEORIGIN instead of DENY, so that should be cool. So it seems the other two points are what's up for some discussion. Anything else? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ticket 14261 - add basic clickjacking protection to Django
I personally do not believe XFrameOptionsMiddleware should be on by default. There are plenty of folks using Django for simple static sites or RESTful APIs where clickjacking doesn't apply. I'd prefer it's something that requires you to intentionally turn it on by adding the middleware to your settings and/or using the decorators on views you want to clickjack protect. With that said, I could change the patch if the core devs say otherwise. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ticket 14261 - add basic clickjacking protection to Django
Luke - I suggest taking a look at the patch, as it works exactly as you describe (i.e. CSRF-like). Only thing that's not in there is having the middleware in the project template but commented out. I can add that in too. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
