Add a setting for CSRF Header name

[hello@…]

CSRF includes a few customizations in settings:
​https://github.com/django/django/blob/master/django/conf/global_settings.py#L544
but neglects allowing the user to set the Header name used by the server.

It would be very helpful to have this setting to use with AngularJS. While AngularJS allows overriding the cookie and header name, it would be better for my workflow (and I'm sure others) to set this on the server side and then AngularJS's CSRF functionality will "just work".

Details on the AngularJS CSRF workings:
​http://docs.angularjs.org/api/ng.$http § Cross Site Request Forgery (XSRF) Protection

Pull request:
​https://github.com/django/django/pull/1958

[Horst Gutmann]

Since also the cookie name is also configurable it definitely makes sense to also make the header name configurable since it might be used from the Django-context. The same is not necessarily true for the name of the form-field so keeping this one hard-coded is IMO valid.

[Susan Tan]

I made a separate PR that addresses other people's suggestions here: ​https://github.com/django/django/pull/1989 Feel free to code review; I'm unsure what test(s) to add.

[Susan Tan]

I made a separate PR that addresses other people's suggestions here: ​https://github.com/django/django/pull/1989 Feel free to code review; I'm unsure what test(s) to add.

[anonymous]

YAPR (Yet Another PR) with a different interpretation for this change: ​https://github.com/django/django/pull/1995

[Unai Zalakain]

I'm +1 on the last implementation (​https://github.com/django/django/pull/1995) but this needs tests and docs. I would also propose to the mailing list to follow a deprecation timeline with the settings moved inside CsrfViewMiddleware. I'd be glad if an issue initially requiring Yet An Other Setting turned out in an issue removing 6 settings.

[WesAlvaro]

Sure. If we're good on the idea, I'll create tests and mail the list. I much prefer the idea of configuring the middleware vs adding settings!

[Tim Graham]

As I noted on the ​mailing list thread: "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."

[anonymous]

Thanks for the comment, I've replied to the thread. An interesting concern, but one that I don't think we should be accommodating.

[Tim Graham]

The idea of moving settings into middleware has been thoroughly rejected on ​a django-developers thread discussing integrating django-secure's middleware. If it can be done in a backwards compatible way, maybe it would make sense to group the CSRF settings into a dictionary as suggested in the thread. See #22734 which discusses doing this for the SMTP & email settings and also has a patch with proof of concept code.

[Carl Meyer]

Noting here that that mailing list thread also eventually reached a fairly negative conclusion about the benefits of grouping related settings into dictionaries. So I think an implementation of this ticket would best just add a new setting.

[Grzegorz Ślusarek]

created pr here:
​https://github.com/django/django/pull/4183

[Tim Graham]

Thanks, but tests and documentation are also required. See our ​patch review checklist for tips. Please uncheck the appropriate flags on this ticket when that's been added.

[Grzegorz Ślusarek]

pr fixed, tests and documentation added

[Tim Graham]

I've added comments for improvement on the PR.

[Grzegorz Ślusarek]

improved patch, squashed changes, updated PR

[Tim Graham <timograham@…>]

In 668d53cd125175eb708cc0af143f47b42cd42153:

Fixed #21495 -- Added settings.CSRF_HEADER_NAME