The admin area, keys and records

Two doors in front of admin

The admin area answers at admin.amapas353.com; /admin on the site’s other addresses sends you there.

1. Cloudflare Access stands in front of the whole address. Only the addresses on the Amapas owners policy get through, after signing in. The Zero Trust team is shared with traveller.org’s admin and this shelf, each with its own policy. Access is managed at Zero Trust → Access controls.
2. The Worker checks Access’s signed token on every admin page and every /api/admin call, against the team and the application’s audience tag (CF_ACCESS_AUD). A request that reached the Worker some other way — the preview address, say — is refused or sent to the admin address, so turning Access off in the dashboard would not open admin to the world.

Staging (staging.amapas353.com, decision 0064) has its own Access application, over the whole address: the public pages too, not only admin. Its Worker checks the signed token on every request. Until that application’s audience tag is in its configuration, staging shows nothing at all, only “not set up yet”. Its admin can copy content from the live site but cannot publish; Publish lives on the live admin and needs the GITHUB_PUBLISH_TOKEN key there.

ADMIN_PREVIEW_TOKEN, the shared password admin used before Access, is still set, by the owners’ choice — but it does nothing while Access is on: the Worker reads it only when CF_ACCESS_AUD is absent. It is the way back in if Access ever has to be switched off (RUNBOOK §3b, step 7).

Keys

Every key is a secret on the Worker (the Worker’s Settings → Variables and Secrets) and nowhere else. The page The stack at a glance lists them by name. None is in the repository, none in these guides, and a session working on the code never holds one: it reads the live state through a read-only Cloudflare token and the site’s own health report.

Everything is written down

• The audit log (Admin → Audit Log) records every change made in admin: who, what, when, and the before and after. It is append-only; nothing on the site can edit or delete it (decision 0031).
• The outbox records every email the site sent, with its status.
• Messages records every guest reply the mail Worker filed.
• Refunds are rows of their own, one per refund.

What is switched on, right now

/api/health — on any of the site’s addresses — answers with the build that is running and a line for each service: the database and photo store, whether Lodgify answered, Stripe (and whether it is in test or live mode), Resend, Turnstile, the screening keys, the ChatGPT pick-up, DMARC and how admin is guarded. It holds no secrets; it is the first thing to read when something looks wrong. The admin Overview screen shows the same facts in words, and the Launch Book’s strip at the top reads them live.

Links in guests’ emails

Every link that opens a guest’s own page — a payment link, a finish-booking link, a booking’s page — carries a token signed with LINK_SIGNING_SECRET and an expiry. The Worker checks both before it shows anything. The Google tag on the public pages is given the page’s address with that token removed.