On Tue, Jul 24, 2012 at 11:37 PM, Rohan Jain <crod...@gmail.com> wrote:
>
> I had one more idea, "Pluggable CSRF checkers".
>
> Currently, the CSRF middleware has two kinds of checks, referer (for
> https) and secret validation token (common). These with origin header
> based checker (if we add it) come in conditional blocks, making
> switching them difficult. So what I propose to do is decouple their
> logic from CSRF middleware and each of them provide a checker. It goes
> like this:
>
> A setting for configuring global CSRF checkers:
>
> CSRF_CHECKERS = {
> 'django.middleware.csrf.checkers.OriginChecker',
> # This one can be strict for https and lax for http
> 'django.middleware.csrf.checkers.RefererChecker',
> # contrib.sessions could provide a csrf checker maintained
> # with sessions. This stores the token in session data.
> 'django.contrib.sessions.csrf_checkers.SessionChecker'
> }
>
I don't think this is a good idea. If you enumerate security features
in settings.py, then later additions won't be picked up by default. If
Django add a new CSRF checking mechanism, we want everybody to take
advantage of it with no modifications.
Ordinarily I agree with you, explicit is better than implicit.
However, in the case of security features, I think this is inverted:
Django sites should be implicitly enrolled in all security mechanisms
if possible, and should be able to explicitly opt out if necessary.
Almost everyone should be using every single protection Django offers
on all their requests, and therefore it should be verbose and
discouraged to turn off these protections.
Best,
Alex Ogier
--
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.
