Challenge 3: The Risk proxy_cache_bypass Alone Doesn't Fix — Solution Walkthrough

What proxy_cache_bypass actually does:

Per this chapter's own material, proxy_cache_bypass only skips
READING from the cache for requests matching the given condition
(here, the logged_in cookie being present). It says nothing about
what gets WRITTEN to the cache, and nothing about responses that were
already cached before this directive was ever added or before a
particular request happened to carry that cookie.

The risk that remains:

If the underlying cache key still doesn't vary by user identity (per
Exercise 2's own scenario, for instance), a request that doesn't
happen to carry the logged_in cookie — or one made before this
directive existed — can still write a personalized response into the
cache under a shared, non-identity-aware key. Any later bypassed
request skips reading that stale entry, but any OTHER non-bypassed
request hitting the same URL can still read that already-cached,
wrongly-shared personalized response. The underlying cache-key
collision the earlier exercise identified is completely untouched by
this fix.

What's actually needed:

Per this chapter's own warning box, genuinely personalized content
needs either an identity-aware cache key (adding something like
$cookie_session_id to proxy_cache_key) or proxy_no_cache to prevent
that content from ever being written to the cache at all — bypassing
reads alone leaves the write side of the problem, and any already-
cached stale entries, fully in place.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise directly applies this chapter's own warning box,
correctly separating what proxy_cache_bypass actually protects (this
specific bypassed read) from what it leaves exposed (writes, and
pre-existing cached entries under a still-shared key).