Repository navigation
Add the human verification step with an embedded live view - #40
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit f7fd933. Configure here.
masnwilliams
left a comment
masnwilliams
left a comment
There was a problem hiding this comment.
lgtm. the double submit on Continue is fixed in 09a2052 and the new KernelManagedAuth test covers it.
three optional cleanups inline, none blocking.
merge order reminder: the test check fails on sdk-contract.test.ts until kernel/kernel#5015 merges and the SDK is regenerated with the new step and choice type, so this should land after that.
| setUIState((current) => { | ||
| if (isTerminal(current)) return current; | ||
| return stateRef.current | ||
| ? deriveUIState(stateRef.current) | ||
| : "awaiting_input"; | ||
| }); |
There was a problem hiding this comment.
optional: this now does almost the same thing as the stale_interaction updater above. re-deriving a screen that isn't submitting gives back the screen it already has, and stateRef.current can't be null once a submit can start, so the "awaiting_input" fallback never runs. one shared updater would cover both:
const leaveSubmitting = () =>
setUIState((current) =>
current === "submitting" && stateRef.current
? deriveUIState(stateRef.current)
: current,
);| captcha_blocked: { | ||
| title: "Verification required", | ||
| description: "A CAPTCHA challenge blocked the login.", | ||
| }, |
There was a problem hiding this comment.
optional: with the description removed, a captcha_blocked failure that has no error_message now shows the generic error copy instead of the captcha text. keeping description: "A CAPTCHA challenge blocked the login." and preferring the server message for this code when one is present would avoid that, and description could stay required for the other codes.
| {errorMessage && <ErrorBanner message={errorMessage} />} | ||
|
|
||
| <LiveViewFrame url={liveViewUrl} /> | ||
|
|
There was a problem hiding this comment.
optional: the reload/retry counters in LiveViewFrame live in refs and don't reset if live_view_url changes, and a failure that's already set keeps the effect inactive for a new url. <LiveViewFrame key={liveViewUrl ?? ""} url={liveViewUrl} /> would start the frame fresh on a new url.
…n, and reset the live view on a new url
context
managed auth logins can now pause on a captcha the browser can't solve (
AWAITING_HUMAN_INTERVENTION) when the connection hashitlon. the component needs a screen where the person completes the check in the login browser and tells us they're done.changes
awaiting_human_interventionUI state andHumanInterventionStep:human_interventionchoice.LiveViewFramethat follows the live view's postMessage protocol: if no video plays within 60s it reloads the frame up to twice, then says to reload the page. a network failure gets one "Try again"; a browser that can't play the stream gets a message and no button.descriptionshows as a note ("{site} is asking to verify again.").human_interventionchoice is kept out ofsign_in_optionsand submitted through the existing sign-in choice path.captcha_blockederror screen shows the API'serror_messagewhen there is one, so a timeout reads "a person was asked to complete it but didn't finish in time", and falls back to "A CAPTCHA blocked the login." when there isn't.humanInterventionNote,humanInterventionLiveView,humanInterventionMessage), demo states and a changeset. the changeset notes that sites with a CSP need the live view origin inframe-src.alternatives considered
testing
head is
221ea9f.bun testpasses (100), including hook tests for the state, the submitted body and the failed-submit path, a component test that Continue stays disabled after an accepted submit until the flow moves on,LiveViewFrametests (one retry for network failures, none for unsupported browsers, other origins ignored, silent stalls reloaded then reported), the error screen description (the server's message when there is one, a captcha fallback when there isn't), and a fresh live view when its url changes. the package builds, the demo typechecks, and prettier is clean.@onkernel/sdk(dev dependency, used only by the contract test) is bumped from 0.93.0 to 0.138.0, the release with the new step and choice type from kernel#5015. typecheck (package and demo), build and prettier are clean, and CI's test job passes, includingsdk-contract.test.ts.related
merge order: kernel#5015 and the SDK release are done; after this, bump the hosted UI before announcing
hitl.Note
Medium Risk
Touches the managed-auth login state machine and submit error recovery, and embeds a third-party origin in an iframe—integrators must allow the live view in CSP.
Overview
Adds
AWAITING_HUMAN_INTERVENTIONsupport for HITL connections when a CAPTCHA blocks automated login. The all-in-one flow rendersHumanInterventionStep, which embeds the session’slive_view_urlviaLiveViewFrame(postMessage watchdog, auto-reloads, one manual retry on transport failures) and submits thehuman_interventionchoice on Continue. The step stays mounted during submit so the iframe is not torn down; failed submits return to the session’s current step instead of defaulting to the input form.The
human_interventionchoice is excluded from sign-in options.captcha_blockederrors prefer the APIerror_messagewhen present. Protocol/types align with@onkernel/sdk0.138.0, plus localization, appearance slots, styles, demo states, README CSPframe-srcnote, and broad test coverage.Reviewed by Cursor Bugbot for commit 221ea9f. Bugbot is set up for automated code reviews on this repo. Configure here.