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 break the default XSS handling.
>
> CSRF, on the other hand, requires an active effort from the start.
> If you start your first project, write a form, and omit the
> template tag, or the tag loader, or the middleware, or the template
> content processor, or don't use a RequestContext, then everything
> falls in a heap of 403s for not entirely obvious (or easy to debug)
> reasons.
I know you're simplifying, but to qualify slightly:
- if you only omit the middleware (by manually disabling it if you
are following the tutorial, or by not following upgrade
instructions for everyone else), everything works except you have
no actual CSRF protection.
- if you only fail to use the CSRF context processor or
RequestContext, you actually get a helpful warning on the
development server terminal.
- if you fail to use the tag loader, you'll get:
TemplateSyntaxError at /foo/
Invalid block tag: 'csrf_token'
which is better than an inscrutable 403.
So it's not *quite* as bad as you say.
Also, we could improve the default CSRF_FAILURE_VIEW so that if DEBUG
is on, on the 403 page the developer gets a link to the CSRF docs or
something, or a check list of things they might have forgotten. That
would improve things a lot IMO. In fact, I like that a lot and I've
implemented it now, ticket updated.
> 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.
If you could make it so that it only inserted the token to the correct
forms, you could perhaps salvage it. The difficulty is that you don't
reliably know what is an external site, AFAICS. You can't just match
the 'action' attribute against the current domain, because the form
might be targeting a different subdomain (which is allowed if you use
the new CSRF_COOKIE_DOMAIN setting). You could possibly use that
setting to help with matching...but I'm concerned that you might not
be able to get it right all the time, and for the exceptions you have
no way of giving the developer the necessary control.
It would still suffer from the fact that you wouldn't be able to do
streaming responses.
> 2. Is there anything we can do with a hybrid approach? As I see
> it, SafeForm was abandoned because it didn't cover the use case of
> hand-crafted forms, but that argument ignores the fact that a good
> proportion of Django forms aren't hand generated. A SafeForm where
> {{ form }} and {{ form.csrf_token }} can be used to include the
> CSRF token avoids the need of RequestContext, loading a tag
> library, or the CSRF context processor, but it doesn't preclude the
> existence of a {% csrf_token %} tag as well for those cases that
> need the manual control.
The APIs for SafeForm that have been proposed so far were fairly bad,
IMO, and significantly worse than the requirement of using
RequestContext. Then you've got the problem of convincing people to
use SafeForm. If you make all built-in forms inherit SafeForm, then
you need a mechanism for turning off the token. It seems to bring
more problems than it solves, and it would be a much bigger change to
the fundamental way we do forms, because Django Forms until now have
not included the <form> tag, which I think the SafeForm solution needs
to do to provide any real benefit. The changes to the tutorial would
be *much* bigger. On top of this, there is the "preferably only one
way to do it" maxim.
> 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 core, not kept isolated as a
> contrib app. Is there anything else that gets easier if we sink
> this into the core? At the very least, the tag loading issues go
> away - are there other possible benefits?
I did think about this occasionally. The only other benefit I can see
is if you could eliminate the need for RequestContext. If the
middleware stuck the CSRF token in some thread local storage, or
something evil like that, you could do it, and you would be down to
simply inserting the {% csrf_token %} in every form that needed it,
plus turning the middleware on. It's a significant improvement in
API, (and a relatively small change to the patch, I think), but fairly
evil in other ways. Having additional request-related things
accessible to the templates is exactly the reason RequestContext
exists, so it seems strange to use another mechanism.
> However, as I said, these ideas are mere zygotes of real thoughts.
> I'll let you know when they've gestated a little more.
I replied to them anyway, hopefully to some benefit.
> By any chance, are you coming to DjangoCon? This would be a
> fantastic subject for a sprint discussion.
No, I'm afraid not (though I'd love to go). I have a full time job
which is not programming related, and it would be too far for me
anyway (I'm in the UK).
Luke
--
I never hated a man enough to give him his diamonds back. (Zsa Zsa
Gabor)
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
-~----------~----~----~----~------~----~------~--~---
