On Wednesday 18 March 2009 15:59:10 Jacob Kaplan-Moss wrote: > On Wed, Mar 18, 2009 at 8:40 AM, Luke Plant <[email protected]> wrote: > > I propose adding the two [CSRF] middleware (view and response) to > > the MIDDLEWARE settings [...] > > I'm a somewhat reluctant +0 on this -- the content re-writing that > the CSRF middleware does has always rubbed me the wrong way. For > one, it'll make implementing streaming responses quite a bit more > difficult. But more importantly it just smells to me.
Yep, agreed. I plan to replace the content re-writing stuff with a template tag which hopefully won't be too nasty. It's just I haven't had time yet, and I'd rather fix the security hole now, and improve the implementation later. The exception mechanisms we've got in place mean that it's not too painful to migrate: - users can add @crsf_response_exempt to views that shouldn't be touched (e.g. places where you know that you want streaming, for example) and don't need the CSRF protection. - in the admin, and other contrib appps, we add the template tag to the templates, and @csrf_response_exempt to the views. - when we are done fixing the admin, we remove 'CsrfResponseMiddleware' from the default middleware, (since we no longer depend on it for security), and recommend that everyone updates their apps and removes it from their settings files. - We then deprecate CsrfResponseMiddleware, and eventually remove it (along with the @csrf_response_exempt decorators which will no longer be needed). Luke -- "My middle name is 'Organised'! My first name is 'Poorly'." 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
