On Monday 31 August 2009 15:26:42 Russell Keith-Magee wrote:
> 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?
For the sake of recording my thoughts, one advantage of keeping it as a
contrib app is that developers can completely replace the CSRF mechanism if
they don't like the bundled one. Simply by doing
s/django.contrib.csrf/thirdparty.csrf/ to their INSTALLED_APPS,
MIDDLEWARE_CLASSES and TEMPLATE_CONTEXT_PROCESSROS settings,
they would replace the CSRF mechanism (including the templatetag library) with
their own. Their own {% csrf_token %} might return an empty string (e.g. if
they were just using Referer checking or Origin checking or something), but
that's fine. The admin and all other apps would then seamlessly use the
different CSRF mechanism.
So keeping it as contrib and not in core might be an advantage if some
websites have special requirements, or the bundled CSRF mechanism becomes
outdated.
Luke
--
"Mistakes: It could be that the purpose of your life is only to serve
as a warning to others." (despair.com)
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
-~----------~----~----~----~------~----~------~--~---
