fix: resolve Control UI token field mismatch between client and server#39716
fix: resolve Control UI token field mismatch between client and server#39716GazeKingNuWu wants to merge 3 commits intoopenclaw:mainfrom
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5e26dff475
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| signedAtMs: number; | ||
| nonce: string; | ||
| }): "v3" | "v2" | null { | ||
| const authToken = params.connectParams.auth?.deviceToken ?? params.connectParams.auth?.token ?? null; |
There was a problem hiding this comment.
Preserve shared-token signature fallback when both tokens are sent
The new authToken selection in resolveDeviceSignaturePayloadVersion always prefers auth.deviceToken over auth.token, which breaks clients that send both fields but sign the payload with the shared token. This is a supported shape in the existing Gateway client (src/gateway/client.ts sets both when token and deviceToken are provided, and signs with token), so these connections now fail at device-signature validation before the auth fallback logic can run. Please keep signature verification compatible by attempting the shared-token payload when both credentials are present.
Useful? React with 👍 / 👎.
Greptile SummaryThis PR fixes a field mismatch between the Control UI client and the gateway server during device authentication, ensuring both sides agree on which credential value to use when building and verifying the signed payload. Key changes:
Both V2 and V3 verification paths are updated consistently, and backward compatibility with older clients is preserved via nullish coalescing fallback. Confidence Score: 4/5
Last reviewed commit: 5e26dff |
ui/src/ui/gateway.ts
Outdated
| authToken = explicitGatewayToken ?? deviceToken; | ||
| const auth = | ||
| authToken || this.opts.password | ||
| authToken || this.opts.password || deviceToken |
There was a problem hiding this comment.
Redundant || deviceToken in auth condition
authToken is assigned on line 223 as explicitGatewayToken ?? deviceToken, so authToken is already truthy whenever deviceToken is truthy (given explicitGatewayToken is always either a non-empty string or undefined per line 217's .trim() || undefined logic). The added || deviceToken guard never introduces a new truthy branch and could mislead future readers into thinking it handles a distinct case.
| authToken || this.opts.password || deviceToken | |
| authToken || this.opts.password |
Prompt To Fix With AI
This is a comment left during a code review.
Path: ui/src/ui/gateway.ts
Line: 225
Comment:
Redundant `|| deviceToken` in auth condition
`authToken` is assigned on line 223 as `explicitGatewayToken ?? deviceToken`, so `authToken` is already truthy whenever `deviceToken` is truthy (given `explicitGatewayToken` is always either a non-empty string or `undefined` per line 217's `.trim() || undefined` logic). The added `|| deviceToken` guard never introduces a new truthy branch and could mislead future readers into thinking it handles a distinct case.
```suggestion
authToken || this.opts.password
```
How can I resolve this? If you propose a fix, please make it concise.
Summary
Fixes #39667 - Control UI token field mismatch
The client was signing with deviceToken but sending auth.token (shared token) to the server.
Changes
AI-assisted PR