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]<javascript:> > > 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] <javascript:>. >> To post to this group, send email to >> [email protected]<javascript:> >> . >> 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/26e80ad7-e134-4ea3-99ed-d6ba83cae2de%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
