Hi Jacob,
Just got back from being away, would have replied earlier otherwise...
> It's simply far too draconian: if I forget to do all steps needed
> to upgrade, all my contrib apps stop working. And then as soon as I
> *do* those steps, all *my* apps that use POST stop working. I just
> can't see that causing anything other than a huge amount of pain
> for all but the most savvy users. Updating every view that handle a
> POST is a *lot* of work for even small apps.
>
> An even bigger problem would be for users of third-party reusable
> apps: my personal blog is a mere 645 lines of code, but there's
> over 10,000 lines of third-party apps I'm building on top of. If I
> want to upgrade to 1.1 and keep using the admin, I need to wait for
> all of those apps to be upgraded to use CSRF protection.
I don't think it is quite so drastic, there are some more alternatives
here that I think you've missed (my fault for not explaining clearly).
Here are two ways to keep things 'working' with minimal effort (these
are scenarios 5 and 4 in my previous email):
1) Install the CSRF app (update INSTALLED_APPS and
TEMPLATE_CONTEXT_PROCESSORS), but don't install the middleware.
Result: everything still works, but no CSRF protection.
2) Install the CSRF app (update INSTALLED_APPS and
TEMPLATE_CONTEXT_PROCESSORS), and install *both* CsrfViewMiddleware
and CsrfResponseMiddleware.
Result: everything still works, including automatic CSRF protection as
it was in Django 1.0 (and template tag protection for contrib apps as
well). Performance: you get the performance hit of the old post
processing method. Completely harmless side effect: you get double
insertion of the CSRF token in the contrib apps (this works fine, it
isn't even invalid HTML).
It seems to me the only two alternatives you could be proposing are:
1) No recommended CSRF solution.
Result: everything works, but no CSRF protection.
2) Recommend using the Django 1.0 CsrfMiddleware
Result: everything works, including automatic CSRF protection, with
its nastiness.
I don't think that 'my' options 1) and 2) are so much worse than
'your' 1) and 2) (not wishing to sound aggressive there!)
So, as I see it the only disaster is if people expect to upgrade to
Django 1.1 without changing any settings, and don't even do basic
tests (like loading any page in the admin that has a form in it).
Of course, you would still want all apps to be updated eventually.
The evil thing is that once updated for the Django 1.1 way, they would
stop working with Django 1.0, due to the presence of {% load csrf %}
and {% csrf_token %} in their templates. This is actually the
nastiest part of the whole thing IMO, but I think it affects lots of
other areas and is fairly inevitable -- any app which is changed to
use Django 1.1 features will break if you run it on 1.0.
I'm sorry if I didn't explain this properly, it's a bit involved and
easy to forget that other people haven't thought about it for hours!
I realise we would need to document the above very clearly, I'm not
sure where info about upgrading needs to go.
I did go through my own external applications and update them, BTW,
and found the process pretty painless (just "ack -i '<form.*POST'" and
fix the templates). And, as described above, I could have postponed
it just by using CsrfResponseMiddleware instead.
Regards,
Luke
--
"Smoking cures weight problems...eventually..." (Steven Wright)
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
-~----------~----~----~----~------~----~------~--~---
