Conversation
A signed-in owner can change the car's ready time without Face ID. Login still uses a passkey. Configure routes stay owner-gated; this one is marked NoStepUp so the ceremony is skipped and the step-up window is not opened. Pairs with srcfl/ftw-webapp#71. Signed-off-by: Fredrik Ahlgren <fredrik@sourceful-labs.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
miravoss26
left a comment
miravoss26
left a comment
There was a problem hiding this comment.
Box-side half of the pair with ftw-webapp#72: adds a NoStepUp route mark, applies it to the two charging-schedule routes (PUT/DELETE .../schedule), and skips the step-up ceremony for them while keeping the owner role check.
Security screen (authz change — same note as on the webapp PR, not blocking): this is the careful version of that change. TestANoStepUpWriteDoesNotOpenTheWindow specifically proves the thing I'd have flagged if it were missing — a NoStepUp write does not open the step-up grace window for a later, still-ceremony-required configure call on the same session (e.g. app-link pairing). Role enforcement is unchanged and covered (TestAViewerCannotSaveASchedule, TestANoStepUpConfigureStillNeedsTheOwner). TestEveryMarkedRouteIsReachable extended to assert NoStepUp resolves correctly per route, so the mark can't silently drift from the routing table.
- Scope is narrow and explicit — only the two schedule routes, not a tier-wide default.
- Rationale is documented in
docs/architecture.mdnext to the existing step-up threat model, not just in the changeset.
No correctness issues, and the one security-relevant behavior change is both deliberate and defended by a test built specifically to catch the failure mode that would matter. Safe to merge from my read.
2 participants
Why
srcfl/ftw-webapp#71: a signed-in owner changing the car's ready time was asked for Face ID again. Login already proved who is asking. That extra ceremony is the wrong cost for a household setting.
The box is the authority. The app cannot skip the prompt until this route accepts the write without a fresh step-up.
What
Schedule
PUTandDELETEstay Configure (a late save is the same instruction). They are markedNoStepUp: owner is enough, no ceremony.A write accepted this way does not open the step-up window. Saving a ready time must not let a later pairing or config write through.
Minting access, replacing the whole config, and moving energy still need a ceremony or a cmd.
Pair
App change: srcfl/ftw-webapp#72
Tests
stepUp; the box stores and clears it.E_SCOPE_DENIED.go test ./internal/appproto/ ./internal/api/ -count=1