feat: auto-fill auth code when opening KiloClaw gateway#745
feat: auto-fill auth code when opening KiloClaw gateway#745pandemicsyn merged 5 commits intomainfrom
Conversation
Eliminate the manual copy-paste step when accessing claw.kilosessions.ai. The Open button now generates a fresh access code and embeds it as an auth_code query parameter in the gateway URL. The worker validates it on GET and sets the auth cookie directly, falling back to the manual form if the code is invalid or expired.
![kilo-code-bot[bot]](https://avatars.githubusercontent.com/in/2193792?s=60&v=4){kind=small}
Code Review SummaryStatus: No New Issues Found | Recommendation: Address existing comments before merge OverviewThis PR refactors the KiloClaw access flow to auto-authenticate users. Instead of displaying a one-time access code for manual copy/paste, the Open button now generates a code behind the scenes, opens a blank window synchronously (to avoid popup blockers), and navigates it to the gateway URL with the code embedded as an Key changes:
Architecture assessment: The refactoring is clean. The Existing review comments (9) already cover the significant concerns:
No additional issues were found beyond what's already flagged. Fix these issues in Kilo Cloud Files Reviewed (6 files)
|
Address PR feedback: - Use URL + searchParams.set() instead of string concatenation to safely append auth_code, avoiding breakage if gatewayUrl has no existing query string. - Remove 400 from redeemCodeAndSetCookie return type since no code path returns it.
| if (code) { | ||
| const url = new URL(gatewayUrl, window.location.origin); | ||
| url.searchParams.set('auth_code', code); | ||
| window.open(url.toString(), '_blank', 'noopener,noreferrer'); |
There was a problem hiding this comment.
[WARNING]: Popup blocker silently wastes the one-time access code
If the browser's popup blocker prevents window.open from opening a new tab, it returns null without throwing. The access code has already been generated and redeemed server-side, but the user never reaches the gateway URL. The code is consumed with no feedback to the user.
Consider checking the return value:
const win = window.open(url.toString(), '_blank', 'noopener,noreferrer');
if (!win) {
toast.error('Popup blocked — please allow popups and try again');
}| <Button | ||
| variant="primary" | ||
| className={OPEN_BUTTON_ACCENT_CLASS} | ||
| disabled={isOpening} |
There was a problem hiding this comment.
[WARNING]: Race condition — button not disabled during concurrent code generation
The "Open" button is only disabled by isOpening, not by isGenerating. If the user clicks "Access Code" first (which sets isGenerating = true), then quickly clicks "Open" before generation completes, two concurrent generateAccessCode() calls will fire. The first code gets overwritten in state and is never used — wasting a one-time access code.
| disabled={isOpening} | |
| disabled={isOpening || isGenerating} |
- Check window.open return value and toast an error if the popup was blocked, so the user knows the code was wasted. - Disable the Open button while isGenerating to prevent racing with an in-flight Access Code generation.
| } | ||
| } | ||
| } catch { | ||
| toast.error('Failed to generate access code for auto-login'); |
There was a problem hiding this comment.
[WARNING]: Misleading error message in catch block
generateAccessCode() catches all its own errors internally and returns null, so this catch block only fires if new URL(gatewayUrl, ...) throws (malformed URL) or something else unexpected happens. The message "Failed to generate access code for auto-login" is misleading in those cases — it should be a generic fallback like "Failed to open — please try again".
| toast.error('Failed to generate access code for auto-login'); | |
| toast.error('Failed to open — please try again'); |
…-auth functionality
| setIsOpening(true); | ||
| const win = window.open('about:blank', '_blank'); | ||
| try { | ||
| const code = await generateAccessCode(); |
There was a problem hiding this comment.
[WARNING]: One-time access code wasted when popup is blocked
If window.open returns null (popup blocked), generateAccessCode() is still called and the one-time code is consumed server-side. The code && win guard on line 23 prevents navigation but the code is already redeemed.
Consider checking win before calling generateAccessCode():
const win = window.open('about:blank', '_blank');
if (!win) {
toast.error('Popup blocked — please allow popups for this site');
setIsOpening(false);
return;
}
try {
const code = await generateAccessCode();
...
St0rmz1
left a comment
St0rmz1
left a comment
There was a problem hiding this comment.
Findings from the first bot round have been addressed. The two remaining bot comments are cosmetic/edge-case. and all looks good to me.
Co-authored-by: kilo-code-bot[bot] <240665456+kilo-code-bot[bot]@users.noreply.github.com>
2 participants
Summary
auth_codequery parameter in the gateway URLChanges
src/app/(app)/claw/components/AccessCodeActions.tsx&auth_code=...to the gateway URLsrc/app/(app)/claw/hooks/useAccessCode.tsgenerateAccessCode()now returnsPromise<string | null>so callers can use the generated codekiloclaw/src/routes/access-gateway.tsredeemCodeAndSetCookie()helper used by both GET and POST handlersauth_codequery parameter and validates it directly (auto-auth flow)Security
auth_codeparameter is already redacted in worker logs (matches the existing/auth/isensitive pattern — verified by existing test)