fix(remote-control): wire control token + post-pairing identity refresh/reconnect#159
Merged
Merged
Conversation
Contributor
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
A small, sanctioned pre-release fix to the device control plane, split out from the later Phase-B PR so it ships in the baseline release:
getControlTokenseam defaulted to() => undefined, sodial()always opened an unauthenticated control socket that the LAN gateway rejects. It now reads the persisted claim/control credential (config.remote_key); the existing local purpose+signature verification (verifyDeviceControlToken) is retained and still drops a non-device-control or unverifiable token, falling back to the key-less path.initIdentity()+initControlChannel()), so a freshly claimed device dials the hub with its new token immediately instead of only after the next boot.authorizationfield; when present, the backend forwards it as thex-ceralive-pairing-authorizationheader on both the pairing-secret registration and the claim requests. A paste field is added to the CeraLive pairing surface inCloudRemoteDialog.2026.7.1(rootpackage.json; federation producer-version doc updated to match).Why
content-type. This wires the device's send-half. The header literal is pre-pinned here (x-ceralive-pairing-authorization); the platform-side acceptance is a separate, later change, so this only sends the header when the operator provides one.How to verify
bun run lint— clean (Biome + backend typecheck + frontend svelte-check + workspace lints).bun test(backend) —1941 pass / 0 fail, including:getControlTokenpresents the persistedremote_key;canDialControlChannel()) without a manualinitIdentity();x-ceralive-pairing-authorizationheader reaches both HTTP calls when present, and is omitted when absent.bun run --filter @ceraui/rpc test—193 pass / 0 fail.pairing.test.ts—9 pass(PairingController forwards the optional authorization).Risks
Low. The token wiring reuses the existing verification gate unchanged — a bad/opaque token still drops to the key-less path, so no device that works today regresses. The reconnect is idempotent and fail-soft (unprovisioned hub URL is logged, not thrown). The authorization header is send-only and conditional; the platform side is intentionally not assumed here. No change to the SRT/SRTLA media path or the BCRPT relay socket.