tapir

174 Commits 1 Branch 36 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
mathias	9cd3f7e934	fix(dex): passwordName must match Dex's internal passwordID() — maps non-[a-z0-9-] to '-' CI / Lint / Test / Vet (push) Failing after 12s Details CI / Build & Import (push) Has been skipped Details Tapir used human-readable substitutions ('@' -> '-at-', '.' -> '-dot-') when deriving the Password CR name from an email. Dex's internal passwordID() maps every non-[a-z0-9-] character to plain '-'. This caused a name mismatch: Tapir wrote the CR as 'mathias-at-d-ma-dot-be', Dex looked it up as 'mathias-d-ma-be', got not-found, and returned 'Invalid credentials' on every invite login — while static configmap passwords (a different code path) worked fine. Diagnosed by adding the email to staticPasswords and confirming login succeeded, proving the kubernetes CR lookup was the failure point.	2026-06-07 11:37:24 +02:00
mathias	c812c71ecc	fix(dex): store raw bcrypt hash in Password CR, not base64-encoded CI / Lint / Test / Vet (push) Successful in 26s Details CI / Build & Import (push) Successful in 12s Details The original NOTE claimed Dex's kubernetes storage types Hash as []byte, requiring the bcrypt string to be base64-encoded before storage. This was wrong: Dex v2.41 stores and compares the hash field as a plain string. The base64-encoding caused every invite login to fail with 'Invalid credentials' because Dex passed the base64 bytes (starting with 'J' not '$') directly to bcrypt. Static passwords in the configmap always used raw bcrypt strings and worked fine — confirming the dynamic CR encoding was the bug.	2026-06-07 09:28:11 +02:00
mathiasandClaude Opus 4.8	e44485df16	feat(dex): in-cluster Password CR client for local-password accounts Writes passwords.dex.coreos.com CRs against the in-cluster Kubernetes API using the pod's service-account token + cluster CA (no kubectl / client-go dependency). NewPasswordClient returns ErrNotInCluster off cluster so the web layer degrades gracefully in dev. Load-bearing: Dex's kubernetes storage types Password.Hash as []byte, which k8s JSON-marshals as base64 — so the `hash` field carries the base64 of the bcrypt string, not the raw string. Storing the raw string makes Dex's base64-decode-on-login produce garbage and every login fail. 409 -> ErrPasswordExists, 401/403 -> ErrForbidden (RBAC missing) so the handler can give precise messages. Tested against an httptest TLS server. bcrypt cost-12 hashing lives in the web handler; golang.org/x/crypto was already a transitive dep (now promoted in go.sum). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-03 23:14:08 +02:00

Author

SHA1

Message

Date

mathias

9cd3f7e934

fix(dex): passwordName must match Dex's internal passwordID() — maps non-[a-z0-9-] to '-'

CI / Lint / Test / Vet (push) Failing after 12s

Details

CI / Build & Import (push) Has been skipped

Details

Tapir used human-readable substitutions ('@' -> '-at-', '.' -> '-dot-') when
deriving the Password CR name from an email. Dex's internal passwordID() maps
every non-[a-z0-9-] character to plain '-'. This caused a name mismatch:
Tapir wrote the CR as 'mathias-at-d-ma-dot-be', Dex looked it up as
'mathias-d-ma-be', got not-found, and returned 'Invalid credentials' on every
invite login — while static configmap passwords (a different code path) worked
fine. Diagnosed by adding the email to staticPasswords and confirming login
succeeded, proving the kubernetes CR lookup was the failure point.

2026-06-07 11:37:24 +02:00

mathias

c812c71ecc

fix(dex): store raw bcrypt hash in Password CR, not base64-encoded

CI / Lint / Test / Vet (push) Successful in 26s

Details

CI / Build & Import (push) Successful in 12s

Details

The original NOTE claimed Dex's kubernetes storage types Hash as []byte,
requiring the bcrypt string to be base64-encoded before storage. This was
wrong: Dex v2.41 stores and compares the hash field as a plain string. The
base64-encoding caused every invite login to fail with 'Invalid credentials'
because Dex passed the base64 bytes (starting with 'J' not '$') directly to
bcrypt. Static passwords in the configmap always used raw bcrypt strings and
worked fine — confirming the dynamic CR encoding was the bug.

2026-06-07 09:28:11 +02:00

mathiasandClaude Opus 4.8

e44485df16

feat(dex): in-cluster Password CR client for local-password accounts

Writes passwords.dex.coreos.com CRs against the in-cluster Kubernetes
API using the pod's service-account token + cluster CA (no kubectl /
client-go dependency). NewPasswordClient returns ErrNotInCluster off
cluster so the web layer degrades gracefully in dev.

Load-bearing: Dex's kubernetes storage types Password.Hash as []byte,
which k8s JSON-marshals as base64 — so the `hash` field carries the
base64 of the bcrypt string, not the raw string. Storing the raw string
makes Dex's base64-decode-on-login produce garbage and every login fail.

409 -> ErrPasswordExists, 401/403 -> ErrForbidden (RBAC missing) so the
handler can give precise messages. Tested against an httptest TLS server.

bcrypt cost-12 hashing lives in the web handler; golang.org/x/crypto was
already a transitive dep (now promoted in go.sum).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-06-03 23:14:08 +02:00