smoketest_bot_token is provisioned every deploy but nothing consumes it #25

New issue

Open

opened 2026-07-31 20:38:46 +00:00 by forgejo-admin · 0 comments

forgejo-admin commented

2026-07-31 20:38:46 +00:00

Owner

on_install mints a long-lived authentik API token for smoketest_bot and stores it as the smoketest_bot_token hook output (celilo/scripts/setup-web.ts). Since #20, nothing in-tree reads it.

It used to be what the three production smoke checks authenticated with — which was the bug in #20. It is an authentik API token (intent: 'api'), an opaque key rather than a signed JWT, so lunacycle's own auth rejects it: the server verifies bearers with jwtVerify(token, jwks) and the SPA decodes them with jwtDecode. health_check now performs a real OIDC login instead.

I left the provisioning in place deliberately — it is a legitimate service-account credential for calling authentik's API, and removing it is a design call rather than a cleanup. There's a comment at the mint site explaining why it must not be wired back into app auth.

Decide:

Keep if there is a use for a bot credential against the authentik API. Worth documenting the intended consumer so the next person doesn't rediscover the JWT trap.
Remove if not — deletes ~15 lines of provisioning, 2–3 authentik round trips per deploy (the on_install timeout comment notes these round trips were already tight enough to need a bump from 60s), and a long-lived credential that exists for no reason. Also drops the stale smoketest_bot_token secret from the module store.

Leaning remove, but it's the operator's call.

Follow-up from #20.

`on_install` mints a long-lived authentik API token for `smoketest_bot` and stores it as the `smoketest_bot_token` hook output (`celilo/scripts/setup-web.ts`). Since #20, nothing in-tree reads it. It used to be what the three production smoke checks authenticated with — which was the bug in #20. It is an authentik **API token** (`intent: 'api'`), an opaque key rather than a signed JWT, so lunacycle's own auth rejects it: the server verifies bearers with `jwtVerify(token, jwks)` and the SPA decodes them with `jwtDecode`. `health_check` now performs a real OIDC login instead. I left the provisioning in place deliberately — it is a legitimate service-account credential for calling **authentik's** API, and removing it is a design call rather than a cleanup. There's a comment at the mint site explaining why it must not be wired back into app auth. **Decide:** - **Keep** if there is a use for a bot credential against the authentik API. Worth documenting the intended consumer so the next person doesn't rediscover the JWT trap. - **Remove** if not — deletes ~15 lines of provisioning, 2–3 authentik round trips per deploy (the `on_install` timeout comment notes these round trips were already tight enough to need a bump from 60s), and a long-lived credential that exists for no reason. Also drops the stale `smoketest_bot_token` secret from the module store. Leaning remove, but it's the operator's call. Follow-up from #20.

forgejo-admin added the

type/tech-debt

area/deploy

priority/low

labels

2026-07-31 20:38:46 +00:00