The main problem I see with this approach is that it would no longer be straightforward for 3rd party code to access these settings. You'd need something akin to get_user_model() to retrieve the currently installed CSRF middleware so you could access its settings.
Take a look here for examples of 3rd party code that accesses a CSRF setting. https://github.com/search?q=settings.CSRF_COOKIE_NAME&ref=cmdform&type=Code On Monday, December 2, 2013 8:05:51 PM UTC-5, Wes Alvaro wrote: > > I agree; that's exactly the issue I'm trying to rectify. I'd like the > backend to be constant and just work. We have many applications that run > off of the same Django setup, essentially differing only in their handlers. > That's why I'd like to configure the backend once and my front-ends (not > shared, doesn't even have to be Angular) can be good to go with Angular > without having to configure each of them (as we are right now). > > Conversation on the PR has changed it from *adding* a setting to *removing > *6 settings. > > I objectively think that this is the best solution. It declutters the > settings module, moving the settings to where they're actually (and only) > used: the middleware class. This makes it stupid easy to subclass and > change the settings to whatever you need. In my case: > > middleware.py: > > class AngularCsrfViewMiddleware(csrf.CsrfViewMiddleware): > HEADER_NAME = 'HTTP_X_XSRF_TOKEN' > > settings.py: > > MIDDLEWARE_CLASSES = ( > 'my.app.middleware.AngularCsrfViewMiddleware', > ) > > Do you agree that this looks like a better solution? I have created a new > PR (#1995 <https://github.com/django/django/pull/1995>) to use this > method and updated the tests. > Obviously, there will need to be a deprecation schedule setup for the > settings that have been moved. > > > Thanks! > -Wes > > On Friday, November 22, 2013 2:25:14 PM UTC-8, Lee Trout wrote: >> >> Looking at it objectively I'm on the fence. Angular's $http is easily >> configurable at the provider level and I feel like the onus is on any >> front-end tool to be flexible enough to work with different servers. At the >> same time if I needed the same code to talk to Django, Flask, and Node then >> I would expect that I could get all of them on some common ground. Of >> course I would probably just roll my own middleware in that case... >> >> I hold that opinion because maintaining a handful of projects, for me, is >> easier by having the backend as the constant and just remembering when I'm >> rolling djangular that I need to config a couple settings when I start off >> with Angular. (Another being setting X-Requested-With so request.is_ajax >> works as expected). >> >> >> On Fri, Nov 22, 2013 at 2:28 PM, Wesley Alvaro <[email protected]> >> wrote: >> >>> I've been using AngularJS with Django, but I have to override the >>> default CSRF cookie/header values in AngularJS since only one of the values >>> (the cookie name) can be overridden in Django. >>> >>> This is a humble request to add a setting for the CSRF header name so >>> that I can maintain it as my "AngularJS CSRF settings" and I'm sure others >>> would like it too. Changing the cookie and header to XSRF-TOKEN >>> and X-XSRF-TOKEN respectively means that CSRF in Angular just works. Nice. >>> With AngularJS's popularity on the sharp incline, I see this being quite a >>> useful-to-many feature. >>> >>> I acknowledge that adding a setting is not ideal, so I welcome any ideas >>> you may have. >>> Pull request here: https://github.com/django/django/pull/1958 >>> >>> Thanks, >>> -Wes >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/django-developers. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/65d2ce93-1d70-4972-b635-e65dcb896c61%40googlegroups.com >>> . >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1a5160a8-fdaa-41e3-b92e-1d6084d2a4b9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
