[Django] #33362: ALLOWED_HOSTS no longer accepts a non-list/tuple iterable.
Django
------------------------------------------+------------------------
Reporter: Carlton Gibson | Owner: nobody
Type: Bug | Status: new
Component: HTTP handling | Version: 4.0
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
------------------------------------------+------------------------
cdd0b213a825fcfe90ae93dcc554fba8c1e5ff5d added `ALLOWED_HOSTS` to the list
of `tuple_settings` that are checked to be lists or tuples in
`Settings.__init__()`.
This causes a regression with settings such as:
{{{
class AllowedHosts:
"""
An allowed hosts proxy, implementing SOME logic to determine
ALLOWED_HOSTS.
"""
DEBUG_ALLOWED_HOSTS = ["localhost", "127.0.0.1", "[::1]"]
def __iter__(self):
if settings.DEBUG:
yield from self.DEBUG_ALLOWED_HOSTS
yield "domain.com"
yield "domain.org"
yield from [
"other-domain.com",
"www.other-domain.com",
]
ALLOWED_HOSTS = AllowedHosts()
}}}
This works fine before Django 4.0 but raises afterwards:
{{{
raise ImproperlyConfigured("The %s setting must be a list or a tuple." %
setting)
django.core.exceptions.ImproperlyConfigured: The ALLOWED_HOSTS setting
must be a list or a tuple.
}}}
We could revert cdd0b213a825fcfe90ae93dcc554fba8c1e5ff5d, or else adjust
the test. I think the force of it is "`iterable()` but not a string"? 🤔
--
Ticket URL: <https://code.djangoproject.com/ticket/33362>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Carlton Gibson | Owner: nobody
Component: HTTP handling | Version: 4.0
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 Mariusz Felisiak):
* status: new => closed
* resolution: => invalid
Comment:
It's [https://docs.djangoproject.com/en/4.0/ref/settings/#allowed-hosts
documented] that `ALLOWED_HOSTS` is ''"a **list** of strings
representing..."'', it was also discussed in one of
[https://github.com/django/django/pull/13927#discussion_r566242010 PRs]. I
wouldn't consider it as a regression, sorry :) I'm of course open to
discussion.
--
Ticket URL: <https://code.djangoproject.com/ticket/33362#comment:1>
Django
Reporter: Carlton Gibson | Owner: nobody
Component: HTTP handling | Version: 4.0
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Carlton Gibson):
OK, we can say that 😜
(It’s worked this way since ≈forever, so it is a change in behaviour, but
there’ll be another way.)
--
Ticket URL: <https://code.djangoproject.com/ticket/33362#comment:2>
Django
Reporter: Carlton Gibson | Owner: nobody
Component: HTTP handling | Version: 4.0
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Adam Johnson):
There's nothing complicated about your class there, it can be determined
at import time right? It only depends on whether DEBUG is True or not.
You could always make your setting a subclass of `list` and override
`__iter__` if really required.
--
Ticket URL: <https://code.djangoproject.com/ticket/33362#comment:3>
Django
Reporter: Carlton Gibson | Owner: nobody
Component: HTTP handling | Version: 4.0
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Carlton Gibson):
The example is simplified, but I can work around, yes. I do feel we've cut
out a legitimate use-case with an overly strict test — it demands more
than we need — but it's not something I want to spend time pushing on now.
(Not a problem!)
--
Ticket URL: <https://code.djangoproject.com/ticket/33362#comment:4>
Django
Reporter: Carlton Gibson | Owner: nobody
Component: HTTP handling | Version: 4.0
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Claude Paroz):
I agree with Carlton, those checks are not totally Pythonic (duck typing
and all...) and could probably be improved.
--
Ticket URL: <https://code.djangoproject.com/ticket/33362#comment:5>