#19946 closed New feature (duplicate)
If DEBUG mode is False and ALLOWED_HOSTS is empty you should get a console warning
Reported by: | Daniel Greenfeld | Owned by: | nobody |
---|---|---|---|
Component: | Uncategorized | Version: | 1.5 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Django 1.5 is challenging to deploy because the ALLOWED_HOSTS setting doesn't appear to throw a meaningful error. Even though it's documented in the release notes and the settings ref, this is a pain point.
Change History (5)
comment:1 by , 12 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
comment:2 by , 12 years ago
Resolution: | duplicate |
---|---|
Status: | closed → new |
Triage Stage: | Unreviewed → Accepted |
I think this is actually raising a different issue which none of the proposed fixes for #19866 would address, which is that you don't get any warning that you've configured ALLOWED_HOSTS
incorrectly until a request actually comes in; there's no warning immediately on firing things up. This was also discussed in preparing the patch, but there were no great solutions proposed.
In general, I'm not sure this is something we can fix, because we have no way of knowing whether you've configured ALLOWED_HOSTS
correctly or not until a request comes in with an actual Host
header. There is one common misconfiguration case we could do something about, though: the case where you've left ALLOWED_HOSTS
empty.
I'm still not sure what we should do exactly in that case. Throwing an error on startup is nasty, because there are plenty of cases where you just want to quick fire up a Django environment with minimal settings to do some non-HTTP-oriented stuff, and it sucks to require ALLOWED_HOSTS
in that situation (we already get flak for requiring SECRET_KEY
that way). I guess we could issue a warning?
I'm reopening this because I think it gets at a basically different issue from #19866 (though related), and I think the fixes for the two issues will be pretty much orthogonal. I'm not sure what the right fix for this one is; accepting the ticket provisionally because I think it is a real problem.
comment:3 by , 12 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
I guess the time when you're most likely to misconfigure ALLOWED_HOSTS
is initial deployment, and you're quite likely to be trying the site yourself to make sure it works at that point. So it may be that fixing #19866 is sufficient for this too, even without any checks on startup, if the 400 error page is somewhat informative (without leaking information that shouldn't be leaked). On that basis I've reconsidered, closing this again as duplicate, sorry for the noise :-)
comment:4 by , 12 years ago
I would like to suggest reopening this ticket, I would like to see a warning in the development server if ALLOWED_HOSTS is either not defined or is an empty list when DEBUG is TRUE. This would be especially useful for those updating older apps to use Django 1.5. Yes, it is clearly stated in the release notes, but as mentioned earlier is also a pain point.
comment:5 by , 12 years ago
I think that's a reasonable suggestion, though there are some open questions, like what sort of warning -- logging? warnings.warn? -- and when it should be raised -- once at startup? whenever request.get_host() is called?
You should probably open a new ticket for it, since it is clearly different from what was originally proposed here (you are proposing a warning when DEBUG is True, not when it is False), and there's already enough confusion in this ticket.
I'm going to close this as a dupe of #19866. The ticket description is different, but it's a manifestation of the same underlying problem -- that the 500 error on ALLOWED_HOSTS failure isn't especially helpful.