docs(website): record the uo-link client config-decrypt contract and the dashboard mixed tier #61

Merged
whitlocktech merged 1 commits from fix/uolink-client-contract-and-sitemode-gate into main 2026-07-28 05:31:54 +00:00
Member

What & why

Doc side of website#107. Two corrections found by a live smoke test of the site (all 200 routes at every access level).

website/ARCHITECTURE.md — the "uoLinkClient never throws" invariant was true of the HTTP call but not of resolving the config, which decrypts the stored auth token and throws when the ciphertext can't be authenticated (SECRET_ENC_KEY rotated, or a DB dump restored under a different key). In practice that 500'd GET /admin/uo-link/config and every char/roster/vendors lookup on both the admin and player surfaces. Spell out that this is now handled inside the client, reported as { ok: false, status: 0, error: 'uo-link config unreadable' } with a distinct ERROR log, and that GET /admin/uo-link/config keeps working — it is the screen an admin needs to re-enter the token and recover.

website/BACKEND_DESIGN.mdGET /dashboard is staff-wide while PUT /site-mode on the same screen is adminOnly, the one place a single screen spans two tiers. That subtlety wasn't written down, and the client had in fact missed it (the toggle rendered for editors, who were then 403'd). Note that the client must gate the control itself rather than relying on the route gate that admitted the user to the page.

How it was tested

Documentation only — no code. Both statements verified against the running server: the four affected routes were reproduced returning 500 with a corrupted auth_token_enc, then re-checked returning 200/503 after the fix; the editor/admin dashboard difference was confirmed in the browser at both roles.

Checklist

  • I have read CONTRIBUTING.md.
  • The change builds and existing tests/checks pass locally.
  • I have added or updated tests/docs where it makes sense.
  • My commits are reasonably scoped with clear messages.

AI-assisted contributions (required)

  • AI tools were used. Tool(s): Claude Code (Opus 5). I have reviewed and understand
    every change, and take responsibility for it. AI-authored commits are
    marked with a Co-Authored-By / Assisted-By trailer.

License

  • I agree that my contribution is licensed under this project's license
    (GNU GPL v3.0 or later), and I have the right to contribute it.
## What & why Doc side of **website#107**. Two corrections found by a live smoke test of the site (all 200 routes at every access level). **`website/ARCHITECTURE.md`** — the "`uoLinkClient` never throws" invariant was true of the HTTP call but *not* of resolving the config, which decrypts the stored auth token and throws when the ciphertext can't be authenticated (`SECRET_ENC_KEY` rotated, or a DB dump restored under a different key). In practice that 500'd `GET /admin/uo-link/config` and every `char`/`roster`/`vendors` lookup on both the admin and player surfaces. Spell out that this is now handled inside the client, reported as `{ ok: false, status: 0, error: 'uo-link config unreadable' }` with a distinct `ERROR` log, and that `GET /admin/uo-link/config` keeps working — it is the screen an admin needs to re-enter the token and recover. **`website/BACKEND_DESIGN.md`** — `GET /dashboard` is staff-wide while `PUT /site-mode` on the same screen is `adminOnly`, the one place a single screen spans two tiers. That subtlety wasn't written down, and the client had in fact missed it (the toggle rendered for editors, who were then 403'd). Note that the client must gate the control itself rather than relying on the route gate that admitted the user to the page. ## How it was tested Documentation only — no code. Both statements verified against the running server: the four affected routes were reproduced returning 500 with a corrupted `auth_token_enc`, then re-checked returning 200/503 after the fix; the editor/admin dashboard difference was confirmed in the browser at both roles. ## Checklist - [x] I have read [CONTRIBUTING.md](CONTRIBUTING.md). - [x] The change builds and existing tests/checks pass locally. - [x] I have added or updated tests/docs where it makes sense. - [x] My commits are reasonably scoped with clear messages. ## AI-assisted contributions (required) - [x] AI tools were used. Tool(s): `Claude Code (Opus 5)`. I have reviewed and understand every change, and take responsibility for it. AI-authored commits are marked with a `Co-Authored-By` / `Assisted-By` trailer. ## License - [x] I agree that my contribution is licensed under this project's license (**GNU GPL v3.0 or later**), and I have the right to contribute it.
wtclaude added 1 commit 2026-07-28 05:25:23 +00:00
Two corrections found by a live smoke test of all 200 routes at every access
level (website PR: fix/uolink-client-throw-and-sitemode-gate).

ARCHITECTURE.md: the "uoLinkClient never throws" invariant was true of the HTTP
call but not of resolving the config, which decrypts the stored auth token and
throws when the ciphertext can't be authenticated (SECRET_ENC_KEY rotated, or a
DB dump restored under a different key). Spell out that this is now handled
inside the client, reported as { ok: false, error: 'uo-link config unreadable' }
with a distinct ERROR log, and that GET /admin/uo-link/config keeps working —
it is the screen an admin needs to re-enter the token and recover.

BACKEND_DESIGN.md: GET /dashboard is staff-wide while PUT /site-mode on the
same screen is adminOnly — the one place a single screen spans two tiers. Note
that the client must gate that control itself rather than relying on the route
gate that admitted the user to the page.

Co-Authored-By: Claude <noreply@anthropic.com>
whitlocktech merged commit b2c27fb285 into main 2026-07-28 05:31:54 +00:00
whitlocktech deleted branch fix/uolink-client-contract-and-sitemode-gate 2026-07-28 05:31:55 +00:00
Sign in to join this conversation.
No description provided.