Django: Ticket Queryhttps://code.djangoproject.com/query?status=!closed&keywords=~client&order=priority
The Web framework for perfectionists with deadlines.en-USDjangohttps://www.djangoproject.com/s/img/site/hdr_logo.gifhttps://code.djangoproject.com/query?status=!closed&keywords=~client&order=priority
Trac 1.2.2https://code.djangoproject.com/ticket/12089
https://code.djangoproject.com/ticket/12089#12089: test client fails to collect sub-contextsMon, 26 Oct 2009 15:12:13 GMTAntti Kaihola<p>
If a main template renders a sub-template with a modified or newly created context, test client's <code>response.context</code> fails to include the modified context. An example using <code>{% with %}</code> and <code>{% include %}</code>:
</p>
<h3 id="main-template.html">main-template.html</h3>
<pre class="wiki">{% with "some-value" as subvariable %}
{% include sub-template.html %}
{% endwith %}
</pre><h3 id="sub-template.html">sub-template.html</h3>
<pre class="wiki">The value of subvariable is "{{ subvariable }}".
</pre><p>
If the test client requests a view which renders <code>main-template.html</code>, the variable <code>subvariable</code> can't be found in <code>response.context</code> as returned by <code>TestClient.get()</code>.
</p>
<p>
The same happens if a custom template tag creates a new context and renders another template.
</p>
Resultshttps://code.djangoproject.com/ticket/12089#changeloghttps://code.djangoproject.com/ticket/12227
https://code.djangoproject.com/ticket/12227#12227: PREPEND_WWW breaks the test clientMon, 16 Nov 2009 19:40:40 GMTAndy Baker<p>
With PREPEND_WWW set to true the test client will always give a 301 status_code:
</p>
<pre class="wiki"> &gt;&gt;&gt; from django.test.client import Client
&gt;&gt;&gt; c = Client()
&gt;&gt;&gt; r = c.get('/admin/', follow=True)
&gt;&gt;&gt; r.status_code
301
&gt;&gt;&gt; r.redirect_chain
[('http://www.testserver/admin/', 301), ('http://www.testserver/admin/', 301)]
</pre>Resultshttps://code.djangoproject.com/ticket/12227#changeloghttps://code.djangoproject.com/ticket/17637
https://code.djangoproject.com/ticket/17637#17637: Client side validation classes for formsSat, 04 Feb 2012 13:18:51 GMTkarthikabinav<p>
Having client side javascript validation for forms having common fields like username having only alphanumerics or password and Confirm password fields matching by providing a validation class.
</p>
<p>
For example a user should be able to do something like :
</p>
<pre class="wiki">forms.TextField(validators ="usernameValidation")
</pre><p>
And automatically a javascript validation for this form field should be in place.
</p>
<p>
One way to do it could be using HTML5 attributes like ticket <a class="closed ticket" href="https://code.djangoproject.com/ticket/16304" title="#16304: New feature: Add HTML5 'placeholder' attribute support to form fields. (closed: wontfix)">#16304</a>.
</p>
Resultshttps://code.djangoproject.com/ticket/17637#changeloghttps://code.djangoproject.com/ticket/24622
https://code.djangoproject.com/ticket/24622#24622: Response "context" and "templates" not available in the Test Client when using Jinja2 - Django 1.8Fri, 10 Apr 2015 15:35:05 GMTrivantis<p>
When using Jinaj2 as the template of choice for a new Django 1.8 project, the Test Client does not populate the <code>context</code> and <code>templates</code> variables of the Response class.
</p>
<p>
If you run the same test using the Django Template Engine, everything works as expected.
</p>
<p>
I understand that the Django Test Client uses signals to populate the variables above, however as a someone new to Django, I was not able to pinpoint where the issues lies.
</p>
Resultshttps://code.djangoproject.com/ticket/24622#changeloghttps://code.djangoproject.com/ticket/28119
https://code.djangoproject.com/ticket/28119#28119: Test client cookies do not take into account server hostnames/domainsMon, 24 Apr 2017 12:27:13 GMTAli Kaafarani<p>
A couple of issues arise in the testing framework when a Django project supports multiple hostnames.
</p>
<ol><li>Cookies received don't set the domain field
</li><li>Cookies with a domain field are still included in requests to a different domain than the one in the cookie
</li></ol><h3 id="Exampleofdomainnotbeingset:">Example of <code>domain</code> not being set:</h3>
<pre class="wiki">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
</pre><p>
Expected result: <code>response.cookies['csrftoken']['domain']</code> was set to the value of <code>SERVER_NAME</code> (default would be <code>testserver</code>).
Rationale: Browsers do this, according to the specification: <a class="ext-link" href="https://tools.ietf.org/html/rfc2965"><span class="icon">​</span>https://tools.ietf.org/html/rfc2965</a> (4.3.1 Interpreting Set-Cookie: Domain Defaults to the request-host)
</p>
<h3 id="Exampleofcookiessentincorrectlytoanotherdomain:">Example of cookies sent incorrectly to another domain:</h3>
<pre class="wiki">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")
</pre><p>
Expected result: On step 4, the client does not include the cookie with non-matching domain name.
Rationale: Using <code>SERVER_NAME</code>, the client should simulate browser behaviour by not sending cookies incorrectly to different hostnames.
</p>
Resultshttps://code.djangoproject.com/ticket/28119#changelog