chore: remove dead AccessClaims struct (#5) #14
2 changed files with 8 additions and 30 deletions
|
|
@ -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,
|
||||
}
|
||||
|
|
@ -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.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue