An obvious self-suggesting solution is to add a new system check that will
check the type of ALLOWED_HOSTS if it is string or not and notify the
developer about possible improper configuration. I think blacklist
checking (string or not) is more appropiate here, but I can be wrong.
--
Ticket URL: <https://code.djangoproject.com/ticket/29606>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_better_patch: 0 => 1
* version: 2.0 => master
* easy: 1 => 0
* has_patch: 0 => 1
* stage: Unreviewed => Accepted
Comment:
[https://github.com/django/django/pull/10151 PR]
I'm not sure if a system check is the way to go. The deployment checks
must be run manually `manage.py check --deploy`. The developer might not
do that as part of a debugging workflow.
--
Ticket URL: <https://code.djangoproject.com/ticket/29606#comment:1>
* cc: Adam (Chainz) Johnson (added)
Comment:
Although it may or may not have helped, I believe in general we should
check as much configuration as possible up front. Another error I myself
have made with ALLOWED_HOSTS is trying "*.example.com" instead of
".example.com" (confusion with "*" being an allowed value) - this (or in
general valid/invalid characters?) could also be checked for.
--
Ticket URL: <https://code.djangoproject.com/ticket/29606#comment:2>
Comment (by Tim Graham):
I'm not opposed to some validation, my suggestion was merely that maybe we
could be more helpful than a system check.
--
Ticket URL: <https://code.djangoproject.com/ticket/29606#comment:3>
* cc: Herbert Fortes (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/29606#comment:4>
Comment (by Nick Mavrakis):
Sorry for the interfere but I would like to add my opinion on this. If
this New Feature is added, then proportionate validations should apply on
other `settings.py` variables (such as `INTERNAL_IPS` to be a list of
valid IPs, `STATIC_ROOT` to be a string of valid pathname etc). See where
it's going? I am not opposed on this improvement but if it's going to
happen, IMO it should happen if not on the whole
[https://docs.djangoproject.com/en/dev/ref/settings/ settings list], at
least on most of them.
Best regards, Nick
--
Ticket URL: <https://code.djangoproject.com/ticket/29606#comment:5>
* owner: nobody => Tomasz Kluczkowski
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/29606#comment:6>
* owner: Tomasz Kluczkowski => (none)
* status: assigned => new
* easy: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/29606#comment:7>
* owner: (none) => Octavio Peri
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/29606#comment:8>
Comment (by Octavio Peri):
Hi, I've assigned this ticket to myself and would like to check my idea
with you before writing any code.
I'm not sure about what Nick Mavrakis stated, maybe that'd be a good idea.
But sticking to this ticket, I believe the best way to proceed is checking
the setting is both iterable and not a str.
I would do so in two places:
1 - In `runserver`, where there's already one check related to
ALLOWED_HOSTS
2 - As a deployment check, that would raise an error if the constraints
are not satisfied.
If you could confirm this would be the way to go, I'd be more than happy
to add them in a PR.
--
Ticket URL: <https://code.djangoproject.com/ticket/29606#comment:9>
Comment (by Adam (Chainz) Johnson):
It needs only be in one place, as a system check. `runserver` runs system
checks at startup already. IMO it should not be a deployment check, as
`ALLOWED_HOSTS` affects use of `runserver` locally too if `DEBUG = False`.
--
Ticket URL: <https://code.djangoproject.com/ticket/29606#comment:10>
Comment (by Akshat1Nar):
Hello, I am Akshat, new to this organisation and I would like to
contribute on this bug. I do understand what rafis is trying to say here,
but I don't understand how to proceed with fixing with this issue. Can
someone tell me what files need to be modified or how to figure that out.
--
Ticket URL: <https://code.djangoproject.com/ticket/29606#comment:11>
Comment (by Marius Räsener):
Wouldn't it be best to check if the entries in `ALLOWED_HOSTS` are
actually valid hosts?
So either IPv4/IPv6 Addresses or some dot separated string with valid
characters.
Maybe I didn't understand how the bug appeared. Or was it something like:
{{{
# wrong
ALLOWED_HOSTS="127.0.0.1"
}}}
vs.
{{{
ALLOWED_HOSTS=["127.0.0.1",]
}}}
also, doesn't work a tuple too?
thx for any hints giving me a better understanding...
--
Ticket URL: <https://code.djangoproject.com/ticket/29606#comment:12>
Comment (by Adam Johnson):
The validation basically only needs to check it's an iterable of strings.
Checking that everything looks like a hostname is very complicated - we
also support wildcards. And it would probably break for someone out there
using a proxy server or middleware that adds something not-quite-host-
looking in the Host header.
--
Ticket URL: <https://code.djangoproject.com/ticket/29606#comment:13>
Comment (by Marius Räsener):
ok, so here's what I came up with for the check:
{{{
def check_allowedhosts(ALLOWED_HOSTS):
if isinstance(ALLOWED_HOSTS,(list,tuple)):
return all(isinstance(element,str) for element in ALLOWED_HOSTS)
else:
return False
}}}
sadly in this case `all([])` returns True so the if else statement is
needed I think ... but of course I'm happy to get hints for a better
implementation.
Besides, where would I put the check and the test?
--
Ticket URL: <https://code.djangoproject.com/ticket/29606#comment:14>
Comment (by Adam Johnson):
See the PR linked in comment #1 for an intial implementation.
--
Ticket URL: <https://code.djangoproject.com/ticket/29606#comment:15>
Comment (by Marius Räsener):
I didn't see the PR earlier, thank you for pointing to it.
Alright, so I could recreate or copy the PR, but there are things still
open to discuss. Can someone point me in the right direction what Tim
Graham is referring to?
Like how could this be more helpful than a system check - maybe something
that's hooked into a test run?
(for a better understanding, I'm trying since yesterday my luck with "easy
picking" issues to contribute something to Django - so please keep in mind
I'm a beginner.)
--
Ticket URL: <https://code.djangoproject.com/ticket/29606#comment:16>
Comment (by Adam Johnson):
Personally I think a system check would be fine. We point users to run
them during deployment in the deplyoment checklist:
https://docs.djangoproject.com/en/3.1/howto/deployment/checklist/
--
Ticket URL: <https://code.djangoproject.com/ticket/29606#comment:17>
Comment (by Marius Räsener):
well, having a app running in production for several years now I never
knew this exists :P
but, whatever - that's my responsibility.
Anyways, I don't have a strong opinion I just have an interest in closing
this issue since I want to be some kind of contributor and head to the
next issue.
So, what needs to be done to merge this and close the issue?
--
Ticket URL: <https://code.djangoproject.com/ticket/29606#comment:18>
Comment (by Mariusz Felisiak):
Replying to [comment:18 Marius Räsener]:
> So, what needs to be done to merge this and close the issue?
The second step is to send PR via GitHub.
--
Ticket URL: <https://code.djangoproject.com/ticket/29606#comment:19>
Comment (by Marius Räsener):
Alright, here is my PR :) https://github.com/django/django/pull/13927
--
Ticket URL: <https://code.djangoproject.com/ticket/29606#comment:20>
Comment (by Marius Räsener):
Should I ping this every ~24 hrs or what could be a good strategy?
--
Ticket URL: <https://code.djangoproject.com/ticket/29606#comment:21>
Comment (by Simon Charette):
Please refer to
[https://docs.djangoproject.com/en/3.1/internals/contributing/triaging-
tickets/#triage-workflow the contributing documentation] to make sure your
patch appears in the review queue.
In this case you'll want to uncheck ''Patch needs improvement''
--
Ticket URL: <https://code.djangoproject.com/ticket/29606#comment:22>
* cc: Marius Räsener (added)
* needs_better_patch: 1 => 0
* owner: Octavio Peri => Marius Räsener
Comment:
I hope that’s the right thing to do...
--
Ticket URL: <https://code.djangoproject.com/ticket/29606#comment:23>
* needs_better_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/29606#comment:24>
Comment (by AdamDonna):
I've recreated the PR and incorporated the feedback from the reviewers.
It's ready for another review at
https://github.com/django/django/pull/14149.
Functionally i think it's good; the docs will need some review (especially
if they needed to be included in other places)
--
Ticket URL: <https://code.djangoproject.com/ticket/29606#comment:25>
* needs_better_patch: 1 => 0
* component: Core (System checks) => Core (Other)
* stage: Accepted => Ready for checkin
Comment:
#26709
--
Ticket URL: <https://code.djangoproject.com/ticket/29606#comment:26>
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"cdd0b213a825fcfe90ae93dcc554fba8c1e5ff5d" cdd0b21]:
{{{
#!CommitTicketReference repository=""
revision="cdd0b213a825fcfe90ae93dcc554fba8c1e5ff5d"
Fixed #29606 -- Added type check for ALLOWED_HOSTS setting.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/29606#comment:27>