1.0.5 — 403 Invalid origin after login (Debian 13 + Caddy)

The status website can open normally but POST /admin/login may be rejected before username/password/2FA verification if the configured public origin is stale or the request contains a valid but non-textually-equal HTTPS origin.

Apply through ArchForge Git

1. Download ArchForge-External-Status-v1.0.5-ADMIN-ORIGIN-FIX-UPDATE-FROM-1.0.4.zip.
2. Extract its contents over the same Git checkout that you use for ArchForge External Status; commit and push changes to your ArchForge Git host.
3. On VPS 2 (your current root account), run:

cd ~/archforge-external-status
git pull --ff-only
bash ./fix-admin-origin.sh

No install.sh or generic update.sh is required. Do not delete or recreate /etc/archforge-status/status.env or SQLite data.

The script verifies the configured Caddy site is status.archforge.nl, checks the existing application's loopback health endpoint, takes a private configuration backup, synchronizes only STATUS_PUBLIC_URL if needed, then uses the existing deployment script to back up SQLite, install and restart with rollback-on-failed-start protection. It tests the external HTTPS login origin without sending any credentials. The verification POST is deliberately missing a valid CSRF token: success means a CSRF rejection, NOT a login.

Afterwards, reload https://status.archforge.nl/admin/login in a fresh tab and log in with your existing password and authenticator code.

Security

Origin and Referer must match the configured HTTPS origin; an attacker cannot bypass this with custom Host or X-Forwarded-* headers. Cookies remain Secure and SameSite=Strict, and all POSTs still need a valid CSRF token. Admin accounts, existing sessions, monitoring and data remain unchanged.

If the script rejects the local HTTPS test

Look only at sanitized web/app service messages:

journalctl -u archforge-status -n 30 --no-pager

Never share /etc/archforge-status/status.env, TOTP secrets or passwords.