Auth Chain Debugger

This page never redirects you and never touches your real logged-in session — every call here is a raw fetch() straight to the backend, so you see the exact response body instead of api.js silently treating a "session expired" response as a reason to log you out. Safe to leave open; it does not affect your real session in other tabs.

1. Config actually loaded on this page

BACKEND_MODE: —
APPS_SCRIPT_URL: —
MYSQL_API_URL: —

These come from the real assets/js/api.js loaded on your server right now — if something here looks wrong or stale, that's the first thing to fix, before anything below matters.

2. Reachability — both backends

(not run yet)
(not run yet)

Expect build to read 2026-09-05.2 on the Apps Script ping. If it reads anything else, the redeploy did not actually take — go back to Deploy → Manage deployments and confirm you edited the version behind the exact URL shown above.

3. Log in (MySQL) and capture a real token

(not run yet)

This does NOT save to your real session (localStorage) — it only keeps the token in this page's memory for the next test. Your real logged-in session elsewhere is untouched.

4. The critical test — call getDashboard directly against Apps Script with that token

(log in above first)

This is exactly what dashboard.html does the moment you land on it after logging in. If this succeeds here but you still get bounced in the real app, the bug is somewhere else (stale cached JS, a different code path) — not the session bridge. If it fails here with "Session expired or invalid", the bridge genuinely isn't working yet, and the two tests below will tell you which half is broken.

5. Isolate which half of the bridge is broken

The bridge has two independent pieces: (a) Apps Script's Script Properties (DB_API_BASE_, MYSQL_SHARED_SECRET_) telling it where/how to ask MySQL, and (b) MySQL's own checkSessionToken action actually answering correctly when asked. This test calls MySQL's side directly, bypassing Apps Script entirely — if THIS works with the secret you type in, the bug is specifically in Apps Script's Script Properties (wrong or missing value), not in MySQL's code. 

(log in above first, then paste a secret to test)

6. What's actually in your browser's storage right now

(not run yet)

Read-only — this button never clears or modifies anything. Useful to confirm there isn't a stale/garbled token sitting around from before. (2026-09-10: idle-timeout auto-logout was removed, so ytcrm_last_activity is no longer written — it's kept in this list only to show a leftover value from an old session if one is still sitting there.)

7. Full connectivity diagnostic — 404 root-cause report

Purpose-built for the "maintenance.html shows a 404" symptom. This does everything sections 1–2 do, plus the one thing that actually tells the two possible causes apart: a JSON 404 body means our own PHP/Apps Script code deliberately rejected the action (not a connectivity problem at all — see db-api/index.php's own comment on why "Unknown action" is intentionally never 404), while an HTML body on a 404 means the request never reached our code — wrong path, dead Apps Script deployment, or a host-level block. Run this once, then copy the report below and share it — the report text alone is enough to diagnose which backend is broken and why, no screenshots needed. 

(not run yet)