Resume joint login after a normal browser startup request

[xrpbanks]

The joint WordPress + CalorieApp login succeeded while the backend was running, but the next attempt after inactivity stalled before any Xaman request. PR #124's hidden document did not resolve this: the user reproduced the startup timeout at 16:21–16:23, and the backend logs show no new startup during that attempt.

The user's direct, top-level visit to the existing backend health URL did wake the service at 15:02–15:03. This change uses that navigation on the main CalorieApp sign-in control and returns automatically to the existing login flow.

Changes:

• The existing public health route accepts an optional resume_login=true flag and issues a non-cacheable 303 to the configured WordPress origin's fixed CalorieApp page once the backend is serving requests. Normal health probes remain JSON.
• The main embedded sign-in control makes a native user-activated navigation in the same tab. A short-lived, one-use sessionStorage intent resumes the existing login only after a trusted parent handshake with the same origin and locale.
• Remove PR Wake sleeping backends with an isolated browser document request #124's ineffective hidden iframe. Keep the rate-limit safeguards and existing Xaman, identity exchange, session, and logout behavior.
• No WordPress plugin, layout, secrets, schema, hosting plan, or new service changes.

Validation:

• Local production frontend build passed, including lint and type checks.
• Targeted frontend tests passed, including the actual control -> navigation intent -> fresh component -> trusted handshake -> exactly one login-start lifecycle.
• Added server tests for the fixed return destination, no cookie creation, ignored untrusted redirect/auth values, and unchanged JSON health probes. GitHub Actions run #415 passed all four jobs, including the full backend suite, frontend checks, repository checks, and WordPress release checks. Pytest is unavailable in this local runtime.

Rollout and acceptance:

• The dashboard showed Auto-Deploy was paused by a preceding specific-commit deployment. With explicit user approval, both existing services were deployed manually to merge commit f689a4acd9bb34f49c6f06267fb22537b17495b0, backend first.
• Backend deployment dep-daent1f40ujc73814mgg became live at 2026-09-06 14:55:05 UTC with successful health checks. Frontend deployment dep-daenu2fqj5pc73a88cvg became live at 14:57:10 UTC.
• Real user cold-start/Xaman acceptance passed on 2026-09-06 at 17:20–17:22 CEST (15:20–15:22 UTC), on Android Brave in the same tab. The supplied screenshots show the sleeping-service page, return to WordPress, Xaman sign-in, the account-control update message, the signed-in WordPress widget, and the connected CalorieApp with the existing food log.
• Keep the installed 0.3.19 maintenance bridge and its refresh-after-success change.
• Corroborating backend logs from the new instance show GET /health?resume_login=true -> 303 at 17:21:45 CEST, login start -> 200 at 17:21:49, identity callback -> 200 at 17:22:20, and authenticated session/food-log reads -> 200 at 17:22:20 and again after the page update at 17:22:25–26.
• Record this deployment plus the installed 0.3.19 maintenance bridge as the accepted baseline for the joint-login repair. This is evidence of the observed cold-start test; it is not a guarantee against every future service failure.

[Copilot]

🟢 Approval recommended

The changes are scoped, align with existing canonical URL/security header conventions, and are backed by targeted frontend and backend tests covering the new wake-and-resume flow.

Pull request overview

This PR updates the “cold backend after inactivity” login path by switching from an embedded hidden-document warmup attempt to a user-activated top-level navigation that wakes the Render backend, then returns to the canonical WordPress CalorieApp page to resume the existing embedded login flow.

Changes:

• Backend /health supports resume_login=true, returning a non-cacheable 303 redirect to the fixed WordPress CalorieApp URL while leaving normal health probes as JSON.
• The embedded Xaman login control performs a same-tab, user-activated _top navigation to the backend health wake URL and uses a short-lived sessionStorage intent to resume login only after a trusted parent handshake.
• Removes the prior hidden iframe wake mechanism and replaces its tests with navigation/intent tests.

File summaries

File	Description
tools/tests/backend_warmup_rate_limit.test.mjs	Removes hidden-document warmup test harness paths now that iframe wake is removed.
tools/tests/backend_wake_navigation.test.mjs	Adds tests for wake-navigation URL guarding and one-time resume intent behavior through trusted handshake.
frontend/lib/backendRequest.ts	Removes the iframe “wake document” mechanism from warmup; keeps readiness probing and rate limiting.
frontend/components/XamanLoginPanel.tsx	Adds wake-navigation link, sessionStorage resume intent helpers, and trusted resume trigger on bridge init.
backend/tests/test_login_wake_return.py	Adds coverage for fixed redirect destination, no session/cookie creation, and unchanged JSON health probes.
backend/app/main.py	Implements /health?resume_login=true 303 redirect to canonical WordPress CalorieApp URL with no-store headers.

Review details

• Files reviewed: 6/6 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.