You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Personal access tokens minted through the CLI webauth login flow get their name truncated at the first hyphen. The webauth approval page parses the request payload by splitting on - and taking a single field for the token name:
port is numeric and pubKeyHex is hex, so the only field that can contain a hyphen is the name, which is last. The CLI builds the name as username@hostname (cli/src/cmd/auth_webauth.go, fmt.Sprintf("%s@%s", username, hostname)), and hostnames/usernames commonly contain hyphens, so params[2] keeps only the part before the first hyphen in the name.
Impact is limited to the token name (a label) - the token key material and authentication are unaffected. The token still works; it just shows up under a wrong, shortened name in the dashboard.
To Reproduce
Steps to reproduce the behavior:
On a machine whose hostname contains a hyphen (e.g. johns-macbook), run the CLI webauth login (phase auth, default webauth mode).
Complete the approval flow in the browser.
Open the dashboard and view the newly created personal access token.
See that the token name is truncated, e.g. john@johns instead of john@johns-macbook.
The full token name is preserved, including any hyphens: john@johns-macbook.
Screenshots
N/A.
Platform you are having the issue on:
Console webauth page (frontend/app/webauth/[requestCode]/page.tsx), any browser. Triggered by the CLI webauth flow; reproducible on any host/user with a hyphen in the name.
Additional context
Root cause: getWebAuthRequestParams uses params[2] rather than rejoining the remaining fields. A parse-safe fix is to treat everything after the second hyphen as the name (params.slice(2).join('-')), or move the payload to a structured format.
This overlaps with feat: honor a CLI-requested token lifetime in the webauth login flow #928 (honoring a CLI-requested token lifetime), which reworks the same payload parsing - the truncation fix falls out of that change. Flagging it as a standalone bug so it is tracked independently of that feature.
Describe the bug
Personal access tokens minted through the CLI
webauthlogin flow get their name truncated at the first hyphen. The webauth approval page parses the request payload by splitting on-and taking a single field for the token name:portis numeric andpubKeyHexis hex, so the only field that can contain a hyphen is the name, which is last. The CLI builds the name asusername@hostname(cli/src/cmd/auth_webauth.go,fmt.Sprintf("%s@%s", username, hostname)), and hostnames/usernames commonly contain hyphens, soparams[2]keeps only the part before the first hyphen in the name.Impact is limited to the token name (a label) - the token key material and authentication are unaffected. The token still works; it just shows up under a wrong, shortened name in the dashboard.
To Reproduce
Steps to reproduce the behavior:
johns-macbook), run the CLI webauth login (phase auth, default webauth mode).john@johnsinstead ofjohn@johns-macbook.Payload trace:
8002-abcd-john@johns-macbook->split(-)->['8002','abcd','john@johns','macbook']-> name =params[2]=john@johns.Expected behavior
The full token name is preserved, including any hyphens:
john@johns-macbook.Screenshots
N/A.
Platform you are having the issue on:
Console webauth page (
frontend/app/webauth/[requestCode]/page.tsx), any browser. Triggered by the CLI webauth flow; reproducible on any host/user with a hyphen in the name.Additional context
getWebAuthRequestParamsusesparams[2]rather than rejoining the remaining fields. A parse-safe fix is to treat everything after the second hyphen as the name (params.slice(2).join('-')), or move the payload to a structured format.