intotheeast-com/docs/working/qa/2026-07-08-pre-trip-readiness-audit.md

Pre-Trip Readiness Audit — 2026-07-08 (overnight)

Scope: everything the trip depends on from the road — the posting pipeline (/post → cache-on-save → add-page-by-form), photo handling, edit mode, auth & sessions, GPX manager, the custom API surface, and prod's anonymous exposure. Method: read-only code audit of the current main + anonymous HTTP probes against production. No code was changed. Findings are prioritized; a 10-minute morning checklist is at the bottom.

---

What was verified and looks solid ✅

• Prod anonymous surface holds. Probed 2026-07-08 (UTC night): GET /api/v1/pages → 401 with a clean JSON error; /post and /gpx-manager render the login form; no X-Powered-By leak. API CORS is same-origin (origins: {}), rate limiting on (120 req/60s), session auth enabled.
• The custom API routes are properly hardened. entry-actions (DELETE entry / reorder photos / trip publish) all require the authenticated owner (site.owner_username, not just any login), enforce api.pages.write, validate slugs as safe single segments, and resolve targets through the page tree via the shared EntryScopeGuard — no raw path concatenation anywhere. The publish route handles the APCu/in-place-write cache gotcha explicitly and never turns a cache-invalidation failure into a fake 500. Audit logging on all three.
• Text can't be lost while composing. post-form.js mirrors every text field to localStorage on each keystroke and clears the draft only on a server-confirmed success notice. Any failure path (validation error, expired session, network drop, closed tab) re-offers the text on the next visit.
• HEIC handling fails closed. Sniffed from bytes (not filename), converted client-side, submit is gated while a conversion is in flight, and a failed conversion skips the file with a visible message instead of uploading a broken HEIC.
• Photo reconcile is fail-safe. Runs exactly once per submit (latched), an empty/missing photo_order touches nothing, only image extensions are ever deleted, and edit-mode targets resolve through the same scope guard.
• Edit-mode photo editor has honest error paths. Failed reorder → revert to last-known-good; failed refresh after a successful save → keeps the saved order; failed batch-add → rollback with an explicit warning when rollback itself was incomplete; 404 on delete treated as convergent success.
• Cache invalidation on post/edit is correct even under prod caching. cache-on-save does deleteAll() + Cache::invalidateCache() (config checksum bump → new page-tree index key), so in-place edits appear without needing APCu-specific clearing on that path.

---

Findings — do before departure (P1)

P1-1 · Prod PHP upload limits are unverified — could block photo posting entirely

php/php-local.ini (100M upload / 500M post) is mounted only into the local Docker container (docker-compose.yml); nothing in scripts/ or deploy/ ships PHP limits to the prod Apache server. If prod runs distro defaults (upload_max_filesize=2M is common), a single modern phone photo (3–8 MB) fails to upload — the exact core use case of the trip. Action: make remote-diag (or a one-off phpinfo check) to read prod's upload_max_filesize / post_max_size / max_file_uploads. If low, add a .user.ini (FPM) or .htaccess php_value (mod_php) via a new make target. The real proof is P1-2's live post with photos.

Resolved 2026-07-09. Confirmed prod was at the 2M default. Fixed by Mischa via Webmin: PHP execution switched from CGI to PHP-FPM (package was already installed) and the upload limits raised in the FPM configuration. Because the setting lives in the server-side FPM config — not in the webroot — it survives fresh Grav installs, so no deploy/-versioned .user.ini / make target is needed. Side benefit: APCu now persists in shared memory, matching the assumptions in the entry-actions publish endpoint's cache invalidation. Config location for future reference: Webmin → PHP-FPM Configuration. Still owed: P1-2's live phone post is the end-to-end proof.

P1-2 · One real end-to-end post from the actual phone, on prod, over cellular

The runbook's pre-launch smoke (handover step 7) calls for one /post submit on prod. After the 2026-07-08 deploy, confirm this happened from the phone you'll travel with, on cellular, with 2+ HEIC photos — that exercises HEIC conversion, FilePond upload, prod PHP limits, cache-on-save under twig.cache:true, and the feed render in one shot. Then edit that entry (reorder + delete a photo), then delete it — the edit/delete paths shipped today and deserve one prod rep.

P1-3 · Session expiry mid-compose: test the 30-minute window once

system.yaml has session.timeout: 1800 (30 min) and form.yaml has refresh_nonce: false. A slow entry written on a train can easily outlive the session; rememberme (enabled, 7-day cookie) should transparently re-auth the next request, but the form nonce and the FilePond flash uploads were created under the old session. The localStorage draft guarantees the text survives whatever happens — but you should see the actual failure mode once now, not first in a hostel. Test: open /post, add a photo, wait 35+ minutes, submit. If it's ugly: consider raising session.timeout in the prod env override (deploy/env/prod/system.yaml, e.g. 4–12 h) — single-owner site, low risk, big comfort. (Per-env override, not the committed dev system.yaml.)

P1-4 · Make sure you can log back in from the road

The rememberme cookie lasts 7 days — on a multi-week trip you will be re-typing the password, possibly on hotel wifi after a cookie wipe. Login throttling is 5 attempts / 10 min (easy to hit with phone typos). Action: confirm the password is in the phone's password manager and test a fresh login on the phone once. Know that after 5 typos you wait 10 minutes — don't panic-retry.

---

Findings — worth doing before departure (P2)

P2-1 · Duplicate home page: user/pages/home/ shadows 00.home/

Both user/pages/home/home.md (old, committed in a440583, carries routes: default: /) and user/pages/00.home/home.md (the real one) exist with the same slug and near-identical content — which is exactly why a silent mix-up would go unnoticed. Which page wins /home (the home.alias target) depends on page-index ordering luck. Action: delete user/pages/home/ (verify / and /home still render the context-aware home from 00.home afterwards, incl. the pre-departure branch).

P2-2 · Docs drift in CLAUDE.md

• active_trip: japan-korea-2026 example — that trip doesn't exist; the real upcoming trip is /trips/denmark-2026 (local site.yaml, uncommitted).
• The entry-actions plugin (three owner-only API routes, shipped with the journal-post-form feature) isn't mentioned in CLAUDE.md's plugin list or architecture sections, and the "post form uses filepond via cache-on-save" description predates the edit-mode photo editor.

P2-3 · No HSTS header on prod

Apache serves without Strict-Transport-Security. One-line header addition; the login form and session cookie deserve it (secure_https: true is already set for the cookie).

P2-4 · Shrink the unused API auth surface

api.yaml enables api_keys + JWT + session auth. The site only uses session auth (gpx-manager, post-form edit, entry-actions). If no API keys are in use (user/config/plugins/api-private.php is untracked/local — not audited), disabling api_keys_enabled/jwt_enabled in config removes two whole credential classes from the attack surface. Not urgent — the endpoints behind them still enforce owner checks.

P2-5 · Confirm the backup path is live

Every road post only exists on the prod disk until git-sync commits it to Gitea. Action: make remote-content-status — confirm git-sync is enabled on prod and the working tree is clean/pushed. (Photos live under pages/, so they ride along in the content repo — the backup covers them too.)

---

Known limitations — accepted, no action (P3)

• Photos are not draft-persisted (File/Blob can't go to localStorage); the restore hint says so explicitly. Re-selecting photos after a failure is the designed trade-off.
• Location/weather helpers depend on free third-party APIs (BigDataCloud reverse-geocode, Open-Meteo). Both are best-effort with manual fallbacks — fine.
• No offline mode. /post needs connectivity to load; composing offline means the phone's notes app. (Logged as an ideation candidate, not a bug.)
• Rate limit 120 req/60s is generous for a single owner; a 6-photo edit batch stays far below it.

---

Morning checklist (~10 minutes + one coffee)

1. make remote-diag → check upload_max_filesize / post_max_size on prod (P1-1). Fix limits first if they're at defaults.
2. From the phone, on cellular, on prod: log in fresh → post a test entry with 2 HEIC photos → verify it's in the feed immediately → edit it (reorder + remove a photo) → delete it (P1-2, P1-4).
3. make remote-content-status → git-sync clean and pushing (P2-5).
4. Optional but cheap: start the 35-minute /post session-expiry test in a background tab while doing the above (P1-3).
5. Queue the P2 cleanups (duplicate home folder, CLAUDE.md drift, HSTS) for a normal dev session — none block departure.