Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#19172 closed Bug (fixed)

test_poisoned_http_host* tests failing when having ADMINS settings populated

Reported by: bernardofontes Owned by: Claude Paroz
Component: contrib.auth Version: 1.4
Severity: Release blocker Keywords: unit tests, auth, admin, mail
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: yes UI/UX: no

Description

After changing the ADMINS settings in the new security release, two tests broke. The output of the tests is:

$ manage test
Creating test database for alias 'default'...
..................................................................................FF......................................................................................................................................................................................................................................................................s........................................................................
======================================================================
FAIL: test_poisoned_http_host (django.contrib.auth.tests.views.PasswordResetTest)
Poisoned HTTP_HOST headers can't be used for reset emails
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/bernardo/virtualenvs/likeaboss/lib/python2.7/site-packages/django/contrib/auth/tests/views.py", line 135, in test_poisoned_http_host
    self.assertEqual(len(mail.outbox), 0)
AssertionError: 1 != 0

======================================================================
FAIL: test_poisoned_http_host_admin_site (django.contrib.auth.tests.views.PasswordResetTest)
Poisoned HTTP_HOST headers can't be used for reset emails on admin views
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/bernardo/virtualenvs/likeaboss/lib/python2.7/site-packages/django/contrib/auth/tests/views.py", line 144, in test_poisoned_http_host_admin_site
    self.assertEqual(len(mail.outbox), 0)
AssertionError: 1 != 0

These tests pass if I don't use the ADMINS configuration setting. To reproduce this test bug, you can just uncommnet this code line on your initial settings file inside the ADMINS setting:

ADMINS = (
   # ('Your Name', 'your_email@example.com'),
)

Change History (17)

comment:1 Changed 4 years ago by Florian Apolloner

Owner: changed from nobody to Florian Apolloner
Status: newassigned

comment:2 Changed 4 years ago by Florian Apolloner

Summary: HTTP_POST headers tests failing when having ADMINS settings populatedtest_poisoned_http_host* tests failing when having ADMINS settings populated

comment:3 Changed 4 years ago by Łukasz Rekucki

Triage Stage: UnreviewedAccepted

comment:4 Changed 4 years ago by anonymous

Owner: changed from Florian Apolloner to anonymous
Status: assignednew
Version: 1.4-rc-21.4

comment:5 Changed 4 years ago by anonymous

have the same problem

comment:6 Changed 4 years ago by anonymous

have the same problem

comment:7 Changed 4 years ago by Claude Paroz

Adding @override_settings(DEBUG_PROPAGATE_EXCEPTIONS=True) for each of those tests solves this particular issue.

comment:8 Changed 4 years ago by Preston Holmes

Severity: NormalRelease blocker

comment:9 Changed 4 years ago by Claude Paroz

Owner: changed from anonymous to Claude Paroz

I will apply the solution proposed in comment:7 if noone opposes.

comment:10 Changed 4 years ago by Aymeric Augustin

Once again, someone reports a test isolation problem, and we're going to hide the symptoms by overriding some settings rather than fix the root cause. It's not like I have a better short term solution to offer, though.

I'd suggest adding a comment explaining why you chose to override DEBUG_PROPAGATE_EXCEPTIONS (and not, say, ADMINS).

comment:11 Changed 4 years ago by Claude Paroz

The test isolation thing is a design issue. I had proposed a patch (see #13394) to completely isolate tests based on a special testing class. Now I think that there is still an idea of doing some level of integration tests in contrib apps tests, so I'm unsure we really want to isolate contrib tests.

comment:12 Changed 4 years ago by Claude Paroz <claude@…>

Resolution: fixed
Status: newclosed

In b774c5993cf80000966ae8f04c985116f98ee5ac:

Fixed #19172 -- Isolated poisoned_http_host tests from 500 handlers

Thanks bernardofontes for the report.

comment:13 Changed 4 years ago by Claude Paroz <claude@…>

In 8c556a32f232ef9e9a3581d7129bd15d4f495d9f:

[1.5.x] Fixed #19172 -- Isolated poisoned_http_host tests from 500 handlers

Thanks bernardofontes for the report.

Backport of b774c5993 from master.

comment:14 Changed 4 years ago by Claude Paroz <claude@…>

In ad2d57a2ccb6316001205739090a2a1d79453207:

[1.4.x] Fixed #19172 -- Isolated poisoned_http_host tests from 500 handlers

Thanks bernardofontes for the report.

Backport of b774c5993 from master.

comment:15 Changed 4 years ago by anonymous

I've just downloaded Django 1.3 from the official site and have the same problem. While status of this task is "fixed".
Am I doing smth wrong?

std output is below:

======================================================================
FAIL: test_poisoned_http_host (django.contrib.auth.tests.views.PasswordResetTest)
Poisoned HTTP_HOST headers can't be used for reset emails


Traceback (most recent call last):

File "/Library/Python/2.7/site-packages/django/contrib/auth/tests/views.py", line 99, in test_poisoned_http_host

self.assertEqual(len(mail.outbox), 0)

AssertionError: 1 != 0

======================================================================
FAIL: test_poisoned_http_host_admin_site (django.contrib.auth.tests.views.PasswordResetTest)
Poisoned HTTP_HOST headers can't be used for reset emails on admin views


Traceback (most recent call last):

File "/Library/Python/2.7/site-packages/django/contrib/auth/tests/views.py", line 109, in test_poisoned_http_host_admin_site

self.assertEqual(len(mail.outbox), 0)

AssertionError: 1 != 0


comment:16 Changed 4 years ago by Claude Paroz

Only security fixes do reach the 1.3.x branch of Django. You will have to live with these errors in Django 1.3, or patch the installed Django version yourself.

comment:17 Changed 4 years ago by anonymous

ok. thanks for your reply.

Note: See TracTickets for help on using tickets.
Back to Top