What about have the output directory outside the repo?
tminuslabs [3 hidden]5 mins ago
Author here. Short version: my Cloudflare Pages build output directory was the repo root, so every committed file was a public URL, including a 150KB internal handoff doc and dot-directories like .claude/ and .github/. No credentials or customer data, but the doc described an admin query parameter that skipped checkout and an unfixed hole in my own schema.
The parts I think are useful beyond my own mistake:
- Two "purge everything" runs did nothing. The headers showed cf-cache-status: DYNAMIC with an age that kept climbing, so the stale copy was in a layer the zone purge doesn't reach. The custom domain served the old file while the pages.dev domain served the clean one.
- A cache-busted request (?cb=random) tells you whether the origin is clean. It does not tell you whether a visitor can still fetch the file. I used it to "verify" the fix twice and was wrong both times.
- What actually closed it was a firewall rule on the path, which runs before cache.
- Rotating the leaked admin string bought almost nothing, because the check was client-side and the value was in the page source all along. The real fix was closing the server-side hole.
Worth a minute: curl your own production domain for README.md, .git/config and your CI files with a plain request. Happy to answer questions.
trollbridge [3 hidden]5 mins ago
Is there a reason you couldn’t have just posted that instead of the LLM generated slop you posted in the website?
ebiester [3 hidden]5 mins ago
Sorry, but I'd have rather read this than the LLM output. This writeup was worth my time.
It's not an anti-ai screed. It's that the official post was... unnecessarily wordy.
HN.zip
The parts I think are useful beyond my own mistake:
- Two "purge everything" runs did nothing. The headers showed cf-cache-status: DYNAMIC with an age that kept climbing, so the stale copy was in a layer the zone purge doesn't reach. The custom domain served the old file while the pages.dev domain served the clean one.
- A cache-busted request (?cb=random) tells you whether the origin is clean. It does not tell you whether a visitor can still fetch the file. I used it to "verify" the fix twice and was wrong both times.
- What actually closed it was a firewall rule on the path, which runs before cache.
- Rotating the leaked admin string bought almost nothing, because the check was client-side and the value was in the page source all along. The real fix was closing the server-side hole.
Worth a minute: curl your own production domain for README.md, .git/config and your CI files with a plain request. Happy to answer questions.
It's not an anti-ai screed. It's that the official post was... unnecessarily wordy.