Premier League Predictor: Django & MySQL — Chapter 11, Exercise 3
====================================================

TASK
Explain what would actually happen if this app were deployed with
DEBUG left True and ALLOWED_HOSTS left empty — both the real
information a visitor could see on a triggered error, and the real
error a normal request would hit regardless.

SOLUTION

These two settings fail in two genuinely different, independent ways.

DEBUG=True left on in production: Django's own debug error page is
designed for a developer's own local machine, so when it's shown, it's
genuinely thorough — a real, unrestricted visitor who manages to
trigger a server error (a 500, for example by hitting a view with
unexpected input that raises an unhandled exception) would see the
full Python traceback, every local variable's own value at each frame
of that traceback, the exact SQL queries Django ran during the
request, and a full dump of settings.py's own values, including
anything sensitive still readable at that point (database credentials
not yet moved to environment variables, for instance). This is a real,
serious information-disclosure risk specifically because it requires
no special access at all — any visitor who can make the app raise an
uncaught exception can see it.

ALLOWED_HOSTS left as an empty list: this fails independently of
DEBUG. Whenever DEBUG=False, Django checks every incoming request's
own Host header against ALLOWED_HOSTS before running any view code at
all. An empty ALLOWED_HOSTS means literally no Host header value is
considered valid, so every single request — not just malicious ones,
every genuine request from a real visitor's own browser — is rejected
immediately with a real 400 Bad Request (a DisallowedHost error),
before fixture_entry, league_table, or any other view this course has
built ever executes. The app would effectively be completely down for
every visitor, not selectively insecure.

So combining both misconfigurations: with DEBUG=True, the app would
actually still SERVE some pages successfully (since Django's own
ALLOWED_HOSTS check is explicitly skipped while DEBUG=True, as a
development convenience) but would leak the sensitive DEBUG=True
error-page information described above on any real error. With
DEBUG=False and ALLOWED_HOSTS still empty, the opposite failure mode
appears instead — the app genuinely can't serve any request at all,
which is a real deployment-breaking bug, not a security leak, and
would be caught immediately the moment anyone tried to actually visit
the deployed site.

WHY THIS WORKS AS AN ANSWER
----------------------------
It treats DEBUG and ALLOWED_HOSTS as two separate, independently
failing settings rather than one combined problem, correctly
identifies that ALLOWED_HOSTS is only even checked once DEBUG=False,
and describes the real, concrete consequence of each misconfiguration
(information disclosure on error vs. every single request being
rejected outright) rather than a vague "it would be insecure."