I expect that an HTTP 400 will be returned to the user for an invalid
HTTP_HOST header and that the CsrfViewMiddleware will not raise an
exception.
To reproduce, configure the application as above, set up a new hostname
(one that is not in ALLOWED_HOSTS) pointing at the Django application
(using the hosts file, for example), and then request that hostname.
--
Ticket URL: <https://code.djangoproject.com/ticket/30091>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* Attachment "error_log.txt" added.
Comment (by Carlton Gibson):
Hi Mark. Do you have an example project you can upload demonstrating this
issue? Thanks!
--
Ticket URL: <https://code.djangoproject.com/ticket/30091#comment:1>
Comment (by Mark Gregson):
Hi Carlton. Not one I can easily share. I'll see if I can create a minimal
project that reproduces it.
--
Ticket URL: <https://code.djangoproject.com/ticket/30091#comment:2>
* Attachment "min_example.diff" added.
Patch to create minimal project reproducing the bug
Comment (by Mark Gregson):
Okay, I've just attached a minimal working example. I've provided it as a
patch to a 'django-admin startproject' site template using Django 1.11.18.
You should just be able to do:
1. django-admin startproject mysite
2. cd mysite
3. patch -p1 < min_example.diff
In this example I've configured ALLOWED_HOSTS = ['localhost'] and added
'127.0.0.1 dummy' to my /etc/hosts file. Requesting http://dummy:8000/
reproduces the ImproperlyConfigured exception.
While producing this example I found that placing CommonMiddleware before
SessionMiddleware was also required to reproduce the bug. I'm unsure if
this is a configuration error; but I couldn't see anything about ordering
of those two middleware classes when I scanned the documentation just now.
Cheers
Mark
--
Ticket URL: <https://code.djangoproject.com/ticket/30091#comment:3>
Comment (by Carlton Gibson):
Hey Mark. Super effort. Thank you. I’ll have a look at the project and get
back to you. 👍
--
Ticket URL: <https://code.djangoproject.com/ticket/30091#comment:4>
* status: new => assigned
* component: Uncategorized => Documentation
* keywords: => middleware
* version: 1.11 => master
* owner: nobody => Carlton Gibson
* has_patch: 0 => 1
* type: Bug => Cleanup/optimization
* stage: Unreviewed => Accepted
Comment:
OK, this is a documentation issue.
Error views are wrapped with `@requires_csrf_token`, so
`SessionMiddleware` must appear before any middleware that may raise an
exception when using `CSRF_USE_SESSIONS`.
The default project template has this correct, so you have to "opt-in" to
this error.
[https://github.com/django/django/pull/10882 PR]
Thanks for the report and the project to reproduce Mark!
--
Ticket URL: <https://code.djangoproject.com/ticket/30091#comment:5>
--
Ticket URL: <https://code.djangoproject.com/ticket/30091#comment:6>
Comment (by Mark Gregson):
Thanks Carlton. Appreciate the quick review.
--
Ticket URL: <https://code.djangoproject.com/ticket/30091#comment:7>
Comment (by Tim Graham <timograham@…>):
In [changeset:"bae66e759faee8513da4b11d3fd16b044b415bdb" bae66e75]:
{{{
#!CommitTicketReference repository=""
revision="bae66e759faee8513da4b11d3fd16b044b415bdb"
Fixed #30091 -- Doc'd middleware ordering requirements with
CSRF_USE_SESSIONS.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/30091#comment:9>
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"89d39dc1d77338b7436abec017e392fc1bdbe3d7" 89d39dc]:
{{{
#!CommitTicketReference repository=""
revision="89d39dc1d77338b7436abec017e392fc1bdbe3d7"
[2.2.x] Fixed #30091 -- Doc'd middleware ordering requirements with
CSRF_USE_SESSIONS.
Backport of bae66e759faee8513da4b11d3fd16b044b415bdb from master.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/30091#comment:8>