On Tuesday 23 December 2008 16:51:46 Bob Thomas wrote: > On Dec 3, 9:14 am, Luke Plant <l.plant...@cantab.net> wrote: > > At the moment, once you've factored everything in, I think 'view > > middleware' + template tag is the way to go, with some more > > custom solution for loginCSRF. The SafeForm ends up having an > > unwieldly API, which means it won't be used or could be used > > incorrectly, it will often require changing a template anyway, > > and it's specific to Django forms. The template tag solution > > would basically require a single line being added to the template > > for each form (plus some settings, once). > > I probably should have said something earlier, since I semi- > volunteered to work on this before. I like the csrf_except > decorator you added. Making it a view middleware also seems like it > would be possible to make a decorator with > decorator_from_middleware, so users can have both an opt-in and > opt-out way of using the middleware, without requiring an awkward > SafeForm class. > > I definitely think that it should be included in the default > middleware, but without even requiring the template tag to use it. > Maybe add a setting for CsrfMiddleware to inject the hidden field > which is on by default but can be disabled if someone wants to use > the template tag. This is an area where Django can easily be secure > by default, as long as we add the flexibility for the users who > need more control.
My plan is this: first, more work needs to be done to the current solution: - the csrf_exempt decorator should also disable the post processing i.e. the function of what is now the CsrfResponseMiddleware. This can probably be done by tagging the response object with some custom attribute. There might be some complications here with serialising the response object, as happens with caching (but then again, in practice there might not, I haven't thought it through). - the csrf_exempt decorator should be decomposed into two decorators, csrf_view_exempt and csrf_response_exempt, which can be applied separately (their functions should be obvious from the names). csrf_exempt becomes a shortcut for applying both these. With this in place, you can disable post-processing on a case by case basis, or globally by using CsrfViewMiddleware instead of CsrfMiddleware. Then, the template tag needs to be implemented. Then, all the docs need updating/rewriting. The recommended usage is: - CsrfViewMiddleware enabled (*not* CsrfMiddleware) - use of the template tag in all forms that need it. The docs should also inform about the quick-and-dirty solution, which is just using the CsrfMiddleware (i.e. the Django 1.0 solution), preferably with a migration path to the proper way i.e. start adding the template tag to the templates, use the csrf_response_exempt on those views, then switch to CsrfViewMiddleware and remove all csrf_response_exempt decorators. As you suggest, an 'opt in' solution using decorator_from_middleware should also be documented. I think the 'recommended' way above is much better though, as it's too easy to forget to opt in. Also in the docs there probably needs to be some mention, under the 'limitations' section of the 'corner case' described in a comment in the current module [1], which becomes relevant once the CsrfResponseMiddleware is no longer recommended. A further modification that would be nice: remove the direct dependency on the session framework. This can be done by having a setting CSRF_SESSION_COOKIE_NAMES. This defaults to [SESSION_COOKIE_NAME]. The csrf token is based on a hash of all cookies specified by this setting. I think we *probably* want to say that if one or more of the cookies is not found, then we assume no session exists. If you want to implement any of this, I'm not planning on working on it for this next week, I'll get in touch when I start in case you've made some progress. Regards, Luke [1] http://code.djangoproject.com/browser/django/trunk/django/contrib/csrf/middleware.py#L70 -- "Yes, wearily I sit here, pain and misery my only companions. And vast intelligence of course. And infinite sorrow. And..." (Marvin the paranoid android) Luke Plant || http://lukeplant.me.uk/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
