chore: remove dead AccessClaims struct (#5) #14

Merged
alvaro merged 1 commit from chore/5-remove-dead-claims into main 2026-07-20 01:09:31 +00:00
2 changed files with 8 additions and 30 deletions
Showing only changes of commit 668ea59030 - Show all commits

View file

@ -1,22 +0,0 @@
use serde::{Deserialize, Serialize};
#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct AccessClaims {
pub sub: String,
pub email: String,
pub family_id: Option<String>,
pub permissions: Vec<String>,
pub token_type: String,
pub iat: i64,
pub exp: i64,
pub jti: String,
}
#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct RefreshClaims {
pub sub: String,
pub token_type: String,
pub iat: i64,
pub exp: i64,
pub jti: String,
}

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 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 sharing is an open design problem). Putting unenforced claims in the token
would imply protection that doesn't exist. would imply protection that doesn't exist.
- `backend/src/auth/claims.rs` *does* define an `AccessClaims` struct with - (Historical: an orphaned `backend/src/auth/claims.rs` once defined a
`family_id`, `permissions`, `token_type`, `jti`. **It is dead code** — not duplicate `AccessClaims` struct with `family_id`/`permissions`/`jti`. It
imported or used anywhere in the source (only in stale compiler scratch was dead code — never declared as a module, never imported — and has been
files under `target/`). It should be removed or wired up; tracked by issue #4. removed; see issue #5.)
- **No `token_type` discriminator.** Access and refresh claims are different - **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 structs, so a token can only decode as one or the other — the field is
redundant and was dropped. 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 - HS256 with a shared secret means the secret is sensitive infrastructure; a
key rotation requires invalidating all tokens (acceptable for the deployment key rotation requires invalidating all tokens (acceptable for the deployment
model, but worth noting vs. asymmetric RS/ES keys). 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 ## Open items
- **Remove `backend/src/auth/claims.rs`** (dead `AccessClaims`) or wire it up - ~~Remove `backend/src/auth/claims.rs` (dead `AccessClaims`) or wire it up
intentionally. Tracked under issue #4. 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 / - When issue #3 (multi-person sharing) is decided, revisit whether family /
share authorization belongs in the JWT or is enforced per-request against a share authorization belongs in the JWT or is enforced per-request against a
shares collection. shares collection.