docs(adr): the forwarding page built ahead of SimpleLogin's sign-in (ADR 0020)
All checks were successful
CI / check (push) Successful in 10s
CI / deploy (push) Successful in 3s

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Tizian 「ティツィアーン」 <raisondetredev@pm.me>
This commit is contained in:
Tizian 「ティツィアーン」 2026-10-23 15:34:51 +02:00
commit ec9426794d
Signed by: raisondetredev
GPG key ID: 07F6FCF405488B64

View file

@ -2,6 +2,20 @@
- **Status:** decided 23 Oct 2026, by the developer (D1–D11 below); the details under
*Proposal* that no decision names are proposed, for review before building.
- **Built (23 Oct 2026), step 1:** the forwarding page (3),
`/simplelogin-callback` on the register's web server (halkyon_base's
`addSimpleLoginCallbackRoute`, Caddy forwarding the path), ahead of the sign-in, so
development signs in through learn.halkyon.eu's page, which its SimpleLogin app
registers too. The state is `<app>-<platform>.<rest>`: the marker one of the module's
fixed table (Learn and Todo, the desktop's loopback on ports 43823 and 43824, or the
app's scheme), the rest 1 to 512 characters of base64url. A 303 carries the code or
SimpleLogin's error (`deny`) with the state and nothing else; whatever is malformed,
repeated or not a GET is refused with a page that repeats nothing. No caching, no
referrer, nothing logged. Android's `assetlinks.json` for Halkyon Learn signed with
the release key (D9) is answered by `deploy/Caddyfile` on learn.halkyon.eu alone,
held to `tool/release/android-certificate.sha256` by a test. The app's intent filter
comes with the sign-in; iOS's associated domains wait for an Apple team ID, so iPhones
come back through the forwarding page and the scheme until then.
- **Builds on:** ADR 0010 (email sign-in), ADR 0011 (profile pages), ADR 0016 (the
register), ADR 0017 (a password, TOTP and the keys).
- **Changes:** ADR 0017's way in on an instance that offers SimpleLogin (its keys, their