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

TASK
Explain why this course never needed CORS configuration anywhere,
tracing the reason back to how templates and static files have been
served since Chapter 4.

SOLUTION

CORS (Cross-Origin Resource Sharing) only becomes a problem when a
browser page loaded from one origin (scheme + host + port) tries to
make a request to a different origin — for example, a React app
served from a CDN at app.example.com calling an API at
api.example.com. Browsers block that kind of cross-origin request by
default unless the server on the receiving end explicitly opts in via
CORS headers.

This course never creates that situation anywhere. Since Chapter 4,
every page a user actually visits — fixture_entry, and every page
built since — is rendered directly by a Django view and returned as
real HTML from this same Django project, at whatever single host this
app is deployed to. The JavaScript on those pages (fixtures.js,
predictions.js, and so on) only ever calls fetch() against relative
paths like /fixtures/42/predictions/upsert/ — paths with no scheme or
host specified at all, which the browser automatically resolves
against the exact same origin the page itself was loaded from.

Static files work the same way: predictor/static/predictor/fixtures.js
is served (in development, by Django's dev server directly; in
production, by WhiteNoise or a reverse proxy, both configured in this
chapter) from that identical origin too, not a separate CDN or asset
host.

Since the page, its JavaScript, its static assets, and every API call
it makes have all lived at one single origin the entire time, there
was never a genuine cross-origin request anywhere in this
application's own real traffic pattern for a browser to need CORS
permission for in the first place. That's the exact same underlying
fact plpredict-fastapi1's own FastAPI sibling relies on with its
StaticFiles mount — a single origin serving everything — just arrived
at here through Django's own server-side template rendering instead.

WHY THIS WORKS AS AN ANSWER
----------------------------
It explains what CORS actually protects against (cross-origin browser
requests specifically), then traces concretely why this app never
produces one — every page, every fetch() call, and every static asset
have shared one single origin since Chapter 4 — rather than just
asserting "there's no CORS problem" without justifying it.