FR: Setting for CSRF Header (pull-request included)

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

FR: Setting for CSRF Header (pull-request included)

Wesley Alvaro
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 [hidden email].
To post to this group, send email to [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: FR: Setting for CSRF Header (pull-request included)

Lee Trout
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 <[hidden email]> 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.

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 [hidden email].
To post to this group, send email to [hidden email].
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 [hidden email].
To post to this group, send email to [hidden email].
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/CAABi-Dqvj%2BDxgu3ys_62jPw%3D6RWjndVZ2dpic0hNqbbDrZZchg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: FR: Setting for CSRF Header (pull-request included)

Wesley Alvaro
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) 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 <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="OO_T8PybyogJ" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">he...@...> 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: <a href="https://github.com/django/django/pull/1958" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fpull%2F1958\46sa\75D\46sntz\0751\46usg\75AFQjCNHKzBaY7KHjDmDhflI2nj3rKWEGAw';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fpull%2F1958\46sa\75D\46sntz\0751\46usg\75AFQjCNHKzBaY7KHjDmDhflI2nj3rKWEGAw';return true;">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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="OO_T8PybyogJ" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">django-develop...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="OO_T8PybyogJ" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">django-d...@googlegroups.com.
Visit this group at <a href="http://groups.google.com/group/django-developers" target="_blank" onmousedown="this.href='http://groups.google.com/group/django-developers';return true;" onclick="this.href='http://groups.google.com/group/django-developers';return true;">http://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/65d2ce93-1d70-4972-b635-e65dcb896c61%40googlegroups.com" target="_blank" onmousedown="this.href='https://groups.google.com/d/msgid/django-developers/65d2ce93-1d70-4972-b635-e65dcb896c61%40googlegroups.com';return true;" onclick="this.href='https://groups.google.com/d/msgid/django-developers/65d2ce93-1d70-4972-b635-e65dcb896c61%40googlegroups.com';return true;">https://groups.google.com/d/msgid/django-developers/65d2ce93-1d70-4972-b635-e65dcb896c61%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/groups/opt_out" target="_blank" onmousedown="this.href='https://groups.google.com/groups/opt_out';return true;" onclick="this.href='https://groups.google.com/groups/opt_out';return true;">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 [hidden email].
To post to this group, send email to [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: FR: Setting for CSRF Header (pull-request included)

Tim Graham-2
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 (<a href="https://github.com/django/django/pull/1995" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fpull%2F1995\46sa\75D\46sntz\0751\46usg\75AFQjCNERBFJaerMVzpVQC3k3pzQX2AFdbQ';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fpull%2F1995\46sa\75D\46sntz\0751\46usg\75AFQjCNERBFJaerMVzpVQC3k3pzQX2AFdbQ';return true;">#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 <[hidden email]> 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: <a href="https://github.com/django/django/pull/1958" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fpull%2F1958\46sa\75D\46sntz\0751\46usg\75AFQjCNHKzBaY7KHjDmDhflI2nj3rKWEGAw';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fpull%2F1958\46sa\75D\46sntz\0751\46usg\75AFQjCNHKzBaY7KHjDmDhflI2nj3rKWEGAw';return true;">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 django-develop...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at <a href="http://groups.google.com/group/django-developers" target="_blank" onmousedown="this.href='http://groups.google.com/group/django-developers';return true;" onclick="this.href='http://groups.google.com/group/django-developers';return true;">http://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/65d2ce93-1d70-4972-b635-e65dcb896c61%40googlegroups.com" target="_blank" onmousedown="this.href='https://groups.google.com/d/msgid/django-developers/65d2ce93-1d70-4972-b635-e65dcb896c61%40googlegroups.com';return true;" onclick="this.href='https://groups.google.com/d/msgid/django-developers/65d2ce93-1d70-4972-b635-e65dcb896c61%40googlegroups.com';return true;">https://groups.google.com/d/msgid/django-developers/65d2ce93-1d70-4972-b635-e65dcb896c61%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/groups/opt_out" target="_blank" onmousedown="this.href='https://groups.google.com/groups/opt_out';return true;" onclick="this.href='https://groups.google.com/groups/opt_out';return true;">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 [hidden email].
To post to this group, send email to [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: FR: Setting for CSRF Header (pull-request included)

Wesley Alvaro
I don't see that as a drawback at all. Third party code should not be concerned with the CSRF cookie information. There's a separation of concerns that's being violated there. Are you speaking from knowledge of 3rd party code needing access to this data or hypothetically? If you have an example, I'd be interested to see why they are accessing it and why they aren't implemented as a CSRF middleware.

On Tuesday, July 8, 2014 10:48:43 AM UTC-7, Tim Graham wrote:
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.

<a href="https://github.com/search?q=settings.CSRF_COOKIE_NAME&amp;ref=cmdform&amp;type=Code" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fsearch%3Fq%3Dsettings.CSRF_COOKIE_NAME%26ref%3Dcmdform%26type%3DCode\46sa\75D\46sntz\0751\46usg\75AFQjCNFx0l7ki1lIo9ja0p6Q-qQNHiTahA';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fsearch%3Fq%3Dsettings.CSRF_COOKIE_NAME%26ref%3Dcmdform%26type%3DCode\46sa\75D\46sntz\0751\46usg\75AFQjCNFx0l7ki1lIo9ja0p6Q-qQNHiTahA';return true;">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 (<a href="https://github.com/django/django/pull/1995" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fpull%2F1995\46sa\75D\46sntz\0751\46usg\75AFQjCNERBFJaerMVzpVQC3k3pzQX2AFdbQ';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fpull%2F1995\46sa\75D\46sntz\0751\46usg\75AFQjCNERBFJaerMVzpVQC3k3pzQX2AFdbQ';return true;">#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 <[hidden email]> 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: <a href="https://github.com/django/django/pull/1958" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fpull%2F1958\46sa\75D\46sntz\0751\46usg\75AFQjCNHKzBaY7KHjDmDhflI2nj3rKWEGAw';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fpull%2F1958\46sa\75D\46sntz\0751\46usg\75AFQjCNHKzBaY7KHjDmDhflI2nj3rKWEGAw';return true;">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 django-develop...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at <a href="http://groups.google.com/group/django-developers" target="_blank" onmousedown="this.href='http://groups.google.com/group/django-developers';return true;" onclick="this.href='http://groups.google.com/group/django-developers';return true;">http://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/65d2ce93-1d70-4972-b635-e65dcb896c61%40googlegroups.com" target="_blank" onmousedown="this.href='https://groups.google.com/d/msgid/django-developers/65d2ce93-1d70-4972-b635-e65dcb896c61%40googlegroups.com';return true;" onclick="this.href='https://groups.google.com/d/msgid/django-developers/65d2ce93-1d70-4972-b635-e65dcb896c61%40googlegroups.com';return true;">https://groups.google.com/d/msgid/django-developers/65d2ce93-1d70-4972-b635-e65dcb896c61%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/groups/opt_out" target="_blank" onmousedown="this.href='https://groups.google.com/groups/opt_out';return true;" onclick="this.href='https://groups.google.com/groups/opt_out';return true;">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 [hidden email].
To post to this group, send email to [hidden email].
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/21078d0e-d283-48b4-a8d2-ef577e395e10%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: FR: Setting for CSRF Header (pull-request included)

Donald Stufft-2


On August 4, 2014 at 3:52:56 PM, Wes Alvaro ([hidden email]) wrote:
> I don't see that as a drawback at all. Third party code should not be
> concerned with the CSRF cookie information. There's a separation of
> concerns that's being violated there. Are you speaking from knowledge of
> 3rd party code needing access to this data or hypothetically? If you have
> an example, I'd be interested to see why they are accessing it and why they
> aren't implemented as a CSRF middleware.
>  

Well any thing with hardcoded cookie names in javascript would break
with this setting although i’m inclined to say you shouldn’t change
the setting in that case.

--  
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/etPan.53dfe589.6b8b4567.1280a%40Thor.local.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: FR: Setting for CSRF Header (pull-request included)

Wesley Alvaro

Yeah, I would agree with you. You should know what your csrf middleware is doing when you enable it so you should know what cookie name, etc is being used for your JS.

On Aug 4, 2014 12:56 PM, "Donald Stufft" <[hidden email]> wrote:


On August 4, 2014 at 3:52:56 PM, Wes Alvaro ([hidden email]) wrote:
> I don't see that as a drawback at all. Third party code should not be
> concerned with the CSRF cookie information. There's a separation of
> concerns that's being violated there. Are you speaking from knowledge of
> 3rd party code needing access to this data or hypothetically? If you have
> an example, I'd be interested to see why they are accessing it and why they
> aren't implemented as a CSRF middleware.
>

Well any thing with hardcoded cookie names in javascript would break
with this setting although i’m inclined to say you shouldn’t change
the setting in that case.

--
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/CABTgSpfQzNafO2%3DwdXZp-Xnuo_mgspYF_M7TWnmMu0L_11AzLg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: FR: Setting for CSRF Header (pull-request included)

Tim Graham-2
Did you look at the github code search link on my previous email? You may substitute the other CSRF setting names and determine if you think people are doing legitimate things or not.

On Monday, August 4, 2014 5:13:57 PM UTC-4, Wes Alvaro wrote:

Yeah, I would agree with you. You should know what your csrf middleware is doing when you enable it so you should know what cookie name, etc is being used for your JS.

On Aug 4, 2014 12:56 PM, "Donald Stufft" <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="cOIN5LBGhIcJ" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">don...@...> wrote:


On August 4, 2014 at 3:52:56 PM, Wes Alvaro (<a href="javascript:" target="_blank" gdf-obfuscated-mailto="cOIN5LBGhIcJ" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">he...@...) wrote:
> I don't see that as a drawback at all. Third party code should not be
> concerned with the CSRF cookie information. There's a separation of
> concerns that's being violated there. Are you speaking from knowledge of
> 3rd party code needing access to this data or hypothetically? If you have
> an example, I'd be interested to see why they are accessing it and why they
> aren't implemented as a CSRF middleware.
>

Well any thing with hardcoded cookie names in javascript would break
with this setting although i’m inclined to say you shouldn’t change
the setting in that case.

--
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/4c5ccb64-3164-4f5d-a119-6249e7d493f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.