chore: remove dead AccessClaims struct (#5)
All checks were successful
Lint and Build / format (pull_request) Successful in 36s
Lint and Build / clippy (pull_request) Successful in 1m42s
Lint and Build / build (pull_request) Successful in 3m47s
Lint and Build / test (pull_request) Successful in 3m57s
Lint and Build / format (push) Successful in 38s
Lint and Build / clippy (push) Successful in 1m58s
Lint and Build / build (push) Successful in 3m48s
Lint and Build / test (push) Successful in 3m57s

backend/src/auth/claims.rs was orphaned dead code: auth/mod.rs never
declared 'mod claims', so the file wasn't compiled into the crate at
all. It defined two structs:
- AccessClaims — referenced nowhere; a latent trap (carried
  family_id/permissions fields that suggested enforcement that doesn't
  exist).
- RefreshClaims — a duplicate of the LIVE RefreshClaims in jwt.rs,
  which is what JwtService actually uses.

Deleted the file. Updated the JWT ADR to mark the open item done and
note the removal historically.

Build/clippy/fmt clean (the file wasn't compiled anyway). Closes #5.
This commit is contained in:
goose 2026-07-19 12:23:31 -03:00
parent 76fd5a8c26
commit 668ea59030
2 changed files with 8 additions and 30 deletions

View file

@ -65,10 +65,10 @@ Note what is **absent** and why:
enforcement is not implemented at the auth layer (see issue #3 — multi-person
sharing is an open design problem). Putting unenforced claims in the token
would imply protection that doesn't exist.
- `backend/src/auth/claims.rs` *does* define an `AccessClaims` struct with
`family_id`, `permissions`, `token_type`, `jti`. **It is dead code** — not
imported or used anywhere in the source (only in stale compiler scratch
files under `target/`). It should be removed or wired up; tracked by issue #4.
- (Historical: an orphaned `backend/src/auth/claims.rs` once defined a
duplicate `AccessClaims` struct with `family_id`/`permissions`/`jti`. It
was dead code — never declared as a module, never imported — and has been
removed; see issue #5.)
- **No `token_type` discriminator.** Access and refresh claims are different
structs, so a token can only decode as one or the other — the field is
redundant and was dropped.
@ -151,13 +151,13 @@ never on the server to protect:
- HS256 with a shared secret means the secret is sensitive infrastructure; a
key rotation requires invalidating all tokens (acceptable for the deployment
model, but worth noting vs. asymmetric RS/ES keys).
- The dead `AccessClaims` struct is a latent trap — someone could wire it up
assuming `family_id`/`permissions` are enforced. Should be deleted.
## Open items
- **Remove `backend/src/auth/claims.rs`** (dead `AccessClaims`) or wire it up
intentionally. Tracked under issue #4.
- ~~Remove `backend/src/auth/claims.rs` (dead `AccessClaims`) or wire it up
intentionally.~~ **Done** — the orphaned file has been deleted (issue #5,
PR #<to fill after open>). The live `Claims` / `RefreshClaims` structs in
`backend/src/auth/jwt.rs` are the only ones.
- When issue #3 (multi-person sharing) is decided, revisit whether family /
share authorization belongs in the JWT or is enforced per-request against a
shares collection.