[Django] #28119: Test client cookies do not take into account server hostnames/domains
Django
-------------------------------------+-------------------------------------
Reporter: Ali | Owner: nobody
Kaafarani |
Type: | Status: new
Uncategorized |
Component: Testing | Version: 1.11
framework | Keywords: test, client,
Severity: Normal | cookie, domain
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
A couple of issues arise in the testing framework when a Django project
supports multiple hostnames.
1. Cookies received don't set the domain field
2. Cookies with a domain field are still included in requests to a
different domain than the one in the cookie
=== Example of `domain` not being set:
{{{
from django.test import Client
client = Client()
# 1. Make a request with explicit SERVER_NAME
response = client.get('/', SERVER_NAME='foo.local')
# 2. Note that response.cookies['csrftoken']['domain'] has no value
}}}
Expected result: `response.cookies['csrftoken']['domain']` was set to
`SERVER_NAME` (default would be `testserver`).
Rationale: Browsers do this, according to the specification:
https://tools.ietf.org/html/rfc2965 (4.3.1 Interpreting Set-Cookie: Domain
Defaults to the request-host)
---
=== Example of cookies sent incorrectly to another domain:
{{{
from django.test import Client
client = Client()
# 1. Make request with explicit SERVER_NAME, receive `csrftoken` cookie
response = client.get('/', SERVER_NAME='foo.local')
# 2. Note that client.cookies['csrftoken'] now has some value (eg.
"123456")
# 3. Set the domain on the cookie
client.cookies['csrftoken']['domain'] = 'bar.local'
# 4. Make request to different domain
response = client.get('/', SERVER_NAME='bar.local')
# 5. Note that client.cookies['csrftoken'] was sent with the request, re-
used by the server, and still has the same value (eg. "123456")
}}}
Expected result: On step 4, the client does not include the cookie with
non-matching domain name.
Rationale: Using SERVER_NAME, the client should simulate browser behaviour
by not sending cookies incorrectly to different hostnames.
--
Ticket URL: <https://code.djangoproject.com/ticket/28119>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: new
Component: Testing framework | Version: 1.11
Severity: Normal | Resolution:
Keywords: test, client, | Triage Stage:
cookie, domain | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* type: Uncategorized => New feature
Old description:
New description:
A couple of issues arise in the testing framework when a Django project
supports multiple hostnames.
1. Cookies received don't set the domain field
2. Cookies with a domain field are still included in requests to a
different domain than the one in the cookie
=== Example of `domain` not being set:
{{{
from django.test import Client
client = Client()
# 1. Make a request with explicit SERVER_NAME
response = client.get('/', SERVER_NAME='foo.local')
# 2. Note that response.cookies['csrftoken']['domain'] has no value
}}}
Expected result: `response.cookies['csrftoken']['domain']` was set to the
value of `SERVER_NAME` (default would be `testserver`).
Rationale: Browsers do this, according to the specification:
https://tools.ietf.org/html/rfc2965 (4.3.1 Interpreting Set-Cookie: Domain
Defaults to the request-host)
---
=== Example of cookies sent incorrectly to another domain:
{{{
from django.test import Client
client = Client()
# 1. Make request with explicit SERVER_NAME, receive `csrftoken` cookie
response = client.get('/', SERVER_NAME='foo.local')
# 2. Note that client.cookies['csrftoken'] now has some value (eg.
"123456")
# 3. Set the domain on the cookie
client.cookies['csrftoken']['domain'] = 'bar.local'
# 4. Make request to different domain
response = client.get('/', SERVER_NAME='bar.local')
# 5. Note that client.cookies['csrftoken'] was sent with the request, re-
used by the server, and still has the same value (eg. "123456")
}}}
Expected result: On step 4, the client does not include the cookie with
non-matching domain name.
Rationale: Using `SERVER_NAME`, the client should simulate browser
behaviour by not sending cookies incorrectly to different hostnames.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/28119#comment:1>
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: new
Component: Testing framework | Version: 1.11
Severity: Normal | Resolution:
Keywords: test, client, | Triage Stage:
cookie, domain | Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Old description:
> A couple of issues arise in the testing framework when a Django project
> supports multiple hostnames.
>
> 1. Cookies received don't set the domain field
> 2. Cookies with a domain field are still included in requests to a
> different domain than the one in the cookie
>
> === Example of `domain` not being set:
>
> {{{
> from django.test import Client
> client = Client()
>
> # 1. Make a request with explicit SERVER_NAME
> response = client.get('/', SERVER_NAME='foo.local')
>
> # 2. Note that response.cookies['csrftoken']['domain'] has no value
> }}}
>
> Expected result: `response.cookies['csrftoken']['domain']` was set to the
> value of `SERVER_NAME` (default would be `testserver`).
> Rationale: Browsers do this, according to the specification:
> https://tools.ietf.org/html/rfc2965 (4.3.1 Interpreting Set-Cookie:
> Domain Defaults to the request-host)
>
> ---
>
> === Example of cookies sent incorrectly to another domain:
>
> {{{
> from django.test import Client
> client = Client()
>
> # 1. Make request with explicit SERVER_NAME, receive `csrftoken` cookie
> response = client.get('/', SERVER_NAME='foo.local')
>
> # 2. Note that client.cookies['csrftoken'] now has some value (eg.
> "123456")
>
> # 3. Set the domain on the cookie
> client.cookies['csrftoken']['domain'] = 'bar.local'
>
> # 4. Make request to different domain
> response = client.get('/', SERVER_NAME='bar.local')
>
> # 5. Note that client.cookies['csrftoken'] was sent with the request, re-
> used by the server, and still has the same value (eg. "123456")
> }}}
>
> Expected result: On step 4, the client does not include the cookie with
> non-matching domain name.
> Rationale: Using `SERVER_NAME`, the client should simulate browser
> behaviour by not sending cookies incorrectly to different hostnames.
New description:
A couple of issues arise in the testing framework when a Django project
supports multiple hostnames.
1. Cookies received don't set the domain field
2. Cookies with a domain field are still included in requests to a
different domain than the one in the cookie
=== Example of `domain` not being set:
{{{
from django.test import Client
client = Client()
# 1. Make a request with explicit SERVER_NAME
response = client.get('/', SERVER_NAME='foo.local')
# 2. Note that response.cookies['csrftoken']['domain'] has no value
}}}
Expected result: `response.cookies['csrftoken']['domain']` was set to the
value of `SERVER_NAME` (default would be `testserver`).
Rationale: Browsers do this, according to the specification:
https://tools.ietf.org/html/rfc2965 (4.3.1 Interpreting Set-Cookie: Domain
Defaults to the request-host)
=== Example of cookies sent incorrectly to another domain:
{{{
from django.test import Client
client = Client()
# 1. Make request with explicit SERVER_NAME, receive `csrftoken` cookie
response = client.get('/', SERVER_NAME='foo.local')
# 2. Note that client.cookies['csrftoken'] now has some value (eg.
"123456")
# 3. Set the domain on the cookie
client.cookies['csrftoken']['domain'] = 'bar.local'
# 4. Make request to different domain
response = client.get('/', SERVER_NAME='bar.local')
# 5. Note that client.cookies['csrftoken'] was sent with the request, re-
used by the server, and still has the same value (eg. "123456")
}}}
Expected result: On step 4, the client does not include the cookie with
non-matching domain name.
Rationale: Using `SERVER_NAME`, the client should simulate browser
behaviour by not sending cookies incorrectly to different hostnames.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/28119#comment:2>
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: new
Component: Testing framework | Version: 1.11
Severity: Normal | Resolution:
Keywords: test, client, | Triage Stage:
cookie, domain | Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Tim Graham):
I'm not sure if we'd want to add this complexity to the test client (which
is fairly dumb and simple). Could you elaborate on the use case? Assuming
you need the functionality for your own project, perhaps you can show us
how complicated it is to implement in a `Client` subclass.
--
Ticket URL: <https://code.djangoproject.com/ticket/28119#comment:3>
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: new
Component: Testing framework | Version: 1.11
Severity: Normal | Resolution:
Keywords: test, client, | Triage Stage:
cookie, domain | Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Ali Kaafarani):
The use case in my project is to test single sign-on functionality. In one
case, we need to log the user in on one site but not the other. Then, when
the user visits the second site, they should be redirected and
automatically authenticated. However, in the test framework, the session
cookie will be sent to both sites after authenticating on only one,
because the hostnames aren't taken into consideration. So the SSO features
cannot be properly tested. I agree that this is probably not a very common
use case, and does add some complexity to the simple client.
I would love to put this together in a Client subclass as a proof of
concept. I will try to do so when I get the free time (although that may
take a while).
--
Ticket URL: <https://code.djangoproject.com/ticket/28119#comment:4>
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: new
Component: Testing framework | Version: 1.11
Severity: Normal | Resolution:
Keywords: test, client, | Triage Stage:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* stage: Unreviewed => Someday/Maybe
--
Ticket URL: <https://code.djangoproject.com/ticket/28119#comment:5>