#27506: HttpRequest.build_absolute_uri throws DisallowedHost
-------------------------------------+-------------------------------------
     Reporter:  Daniel Hahler        |                    Owner:  nobody
         Type:                       |                   Status:  new
  Cleanup/optimization               |
    Component:  HTTP handling        |                  Version:  1.10
     Severity:  Normal               |               Resolution:
     Keywords:                       |             Triage Stage:
                                     |  Unreviewed
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------
Changes (by Tim Graham):

 * cc: Carl Meyer, Florian Apolloner (added)


Old description:

> I've noticed that using ``build_absolute_uri`` might throw
> ``DisallowedHost``, which looks like an unexpected side effect.
>
> This is used for example by opbeat_python
> (https://github.com/opbeat/opbeat_python/blob/1b1e299d84b902c362e5833d6990e61b80c4a29e/opbeat/contrib/django/client.py#L125,
> called when capturing
> (https://github.com/opbeat/opbeat_python/blob/1b1e299d84b902c362e5833d6990e61b80c4a29e/opbeat/contrib/django/client.py#L149))
> to add additional information to a captured event.
>
> This happens already during some exceptional state, where an extra
> exception causes extra issues - another project being affected seems to
> be django-slack (https://github.com/lamby/django-slack/issues/40).
>
> I've not investigated much, but it looks like Django uses this as a
> central place to handle/throw the `DisallowedHost` exception?!
>
> Is there another API that should be used instead?

New description:

 I've noticed that using `HttpRequest.build_absolute_uri()` might throw
 `DisallowedHost`, which looks like an unexpected side effect.

 This is used for example by opbeat_python
 
(https://github.com/opbeat/opbeat_python/blob/1b1e299d84b902c362e5833d6990e61b80c4a29e/opbeat/contrib/django/client.py#L125,
 called when capturing
 
(https://github.com/opbeat/opbeat_python/blob/1b1e299d84b902c362e5833d6990e61b80c4a29e/opbeat/contrib/django/client.py#L149))
 to add additional information to a captured event.

 This happens already during some exceptional state, where an extra
 exception causes extra issues - another project being affected seems to be
 django-slack (https://github.com/lamby/django-slack/issues/40).

 I've not investigated much, but it looks like Django uses this as a
 central place to handle/throw the `DisallowedHost` exception.

 Is there another API that should be used instead?

--

Comment:

 I seem to remember having a similar thought that `HttpRequest` seemed like
 an usual place to do that validation, but I never investigated if there
 could be a better design.

 Adding Carl to CC because he authored the addition of
 `settings.ALLOWED_HOSTS` (d51fb74360b94f2a856573174f8aae3cd905dd35). Maybe
 he remembers something about that. I found a comment from him in the
 private security tracker for the patch that has this todo item:

  Consider validating all requests instead of only when `get_host()` is
 called, to make it less likely a misconfigured whitelist will be missed?
 I'm now leaning away from this, because it seems cleaner to only do the
 work when the value is requested, but I do think it's problematic that it
 could be so easy to deploy and forget to configure `ALLOWED_HOSTS` until
 someone tries to send a password reset email or something.

 with Florian's reply:

 > * `CommonMiddleware` checks the host every request.
 > * CSRF middleware checks the host on every secure request.
 > So essentially you are most likely checking it all the time already (So
 I guess we could move that check up in the wsgi handling…)

--
Ticket URL: <https://code.djangoproject.com/ticket/27506#comment:2>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.7cc0fec178fdabe98230fc715f10a61b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to