Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#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


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 Changed 10 years ago by Russell Keith-Magee

Resolution: duplicate
Status: newclosed

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.

comment:2 Changed 10 years ago by Carl Meyer

Resolution: duplicate
Status: closednew
Triage Stage: UnreviewedAccepted

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.

Last edited 10 years ago by Carl Meyer (previous) (diff)

comment:3 Changed 10 years ago by Carl Meyer

Resolution: duplicate
Status: newclosed

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 :-)

Last edited 10 years ago by Carl Meyer (previous) (diff)

comment:4 Changed 10 years ago by Nate Dudenhoeffer <ndudenhoeffer@…>

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 Changed 10 years ago by Carl Meyer

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.

Note: See TracTickets for help on using tickets.
Back to Top