feat(binjovi): register the staging dashboard login client #703

Merged

binjovi-bot merged 1 commit from feat/binjovi-staging-ui-oauth into trunk

2026-09-13 12:44:25 +00:00

sean commented

2026-09-13 12:37:08 +00:00

Owner

First of three pull requests that make the staging dashboard at https://binjovi.dev/ open in a normal browser.

Why it does not today: staging routes straight to the app with no login proxy, and Kratos pins its session cookie to sean.farm, so a .dev host can never carry the production session. The app then answers 401 invalid_identity to every browser, which is what the availability gate expects of an anonymous request and also what every operator gets.

The design: Oathkeeper stays the first hop for binjovi.dev, exactly as for production, so the gate keeps its 401. A small oauth2-proxy on the host holds a session cookie of its own, and Oathkeeper's cookie_session authenticator asks that proxy's /oauth2/userinfo instead of Kratos. That proxy is a Hydra browser client, and this pull request registers it.

kubernetes/flux/infrastructure/binjovi/staging-ui-oauth.yaml: the client binjovi-staging-ui (authorization code + refresh token, openid profile email offline_access, redirect https://binjovi.dev/oauth2/callback, consent skipped as for every first-party client here); generated client and cookie secrets; a ClusterSecretStore whose reader can get exactly that one Secret and which serves only binjovi-staging. Modelled on availability-agent-oauth.yaml, the argocd/registrar.yaml client shape, and the profiler-oauth.yaml read-back check.
tests/binjovi.sh: the file in the exact resource list, plus twelve assertions on the client shape, the store's namespace condition and the reader's resourceNames. Red before the file, green after.
The digest policy comment gains the proxy Deployment as the second pod maker in binjovi-staging.

tests/check.sh passes in full. All eight objects validate with kubectl apply --dry-run=server. The oauth2-proxy Deployment, the route split and the BINJOVI_UI_ORIGIN change follow in the binjovi repository; the Oathkeeper rules and the ReferenceGrant follow in sean/ory.

https://claude.ai/code/session_01XdBRc9CHgFhAxCyHbdVtt6

First of three pull requests that make the staging dashboard at `https://binjovi.dev/` open in a normal browser. Why it does not today: staging routes straight to the app with no login proxy, and Kratos pins its session cookie to `sean.farm`, so a `.dev` host can never carry the production session. The app then answers `401 invalid_identity` to every browser, which is what the availability gate expects of an anonymous request and also what every operator gets. The design: Oathkeeper stays the first hop for `binjovi.dev`, exactly as for production, so the gate keeps its 401. A small oauth2-proxy on the host holds a session cookie of its own, and Oathkeeper's `cookie_session` authenticator asks that proxy's `/oauth2/userinfo` instead of Kratos. That proxy is a Hydra browser client, and this pull request registers it. - `kubernetes/flux/infrastructure/binjovi/staging-ui-oauth.yaml`: the client `binjovi-staging-ui` (authorization code + refresh token, `openid profile email offline_access`, redirect `https://binjovi.dev/oauth2/callback`, consent skipped as for every first-party client here); generated client and cookie secrets; a `ClusterSecretStore` whose reader can `get` exactly that one Secret and which serves only `binjovi-staging`. Modelled on `availability-agent-oauth.yaml`, the `argocd/registrar.yaml` client shape, and the `profiler-oauth.yaml` read-back check. - `tests/binjovi.sh`: the file in the exact resource list, plus twelve assertions on the client shape, the store's namespace condition and the reader's `resourceNames`. Red before the file, green after. - The digest policy comment gains the proxy Deployment as the second pod maker in `binjovi-staging`. `tests/check.sh` passes in full. All eight objects validate with `kubectl apply --dry-run=server`. The oauth2-proxy Deployment, the route split and the `BINJOVI_UI_ORIGIN` change follow in the binjovi repository; the Oathkeeper rules and the ReferenceGrant follow in `sean/ory`. https://claude.ai/code/session_01XdBRc9CHgFhAxCyHbdVtt6

sean added 1 commit

2026-09-13 12:37:09 +00:00

feat(binjovi): register the staging dashboard login client

binjovi/ci Binjovi failed the frozen plan

Details

cf1937de7c

The staging dashboard at binjovi.dev answers 401 to every browser. Kratos
pins its session cookie to sean.farm, so a .dev host can never carry the
production session. A login proxy on that host holds a session of its own,
and that proxy is a Hydra browser client.

This registers the client: the authorization code flow with a refresh token,
the email claim for the dashboard identity, one redirect URI on binjovi.dev,
and consent skipped as it is for every first-party client here. The client
secret and the cookie secret are generated, and one store delivers them to
binjovi-staging through a reader that can get exactly that one Secret.

The proxy itself, its route and its Oathkeeper rules follow in the binjovi
and ory repositories.

Claude-Session: https://claude.ai/code/session_01XdBRc9CHgFhAxCyHbdVtt6

sean force-pushed feat/binjovi-staging-ui-oauth from cf1937de7c

binjovi/ci Binjovi failed the frozen plan

Details

to d97556176a

binjovi/ci A newer source or plan superseded this Build

Details

2026-09-13 12:41:48 +00:00

Compare

sean force-pushed feat/binjovi-staging-ui-oauth from d97556176a

binjovi/ci A newer source or plan superseded this Build

Details

to aaabf4115a