Show the credential overlay when the page asks for the key as it loads - #87
Merged
Conversation
popen2
enabled auto-merge
August 21, 2026 13:40
The overlay was injected on `dom-ready`, which is after the page's own scripts have run. A sign-in page that starts listening for the security key as it boots — Google's 2SV challenge does exactly that — has already called `navigator.credentials.get()` by then, so wrapping `navigator.credentials` afterwards wrapped nothing: no toast, no window title, no dock bounce, no log line. An AWS SSO login backed by Google showed the user the same silent, apparently-hung window as before issue #17 was fixed. Register the overlay through the WebContents debugger instead, with `Page.addScriptToEvaluateOnNewDocument`, so it runs at document start in the page's own world — before any script the page ships, and again on the cross-origin hop from AWS to the identity provider, which moves the page to a different renderer process. Three details all fail silently and are spelled out where they live: - `Page.enable` has to come first. Without it the registration resolves and does nothing. - There has to be a renderer to talk to. On a window that has not loaded anything the command never resolves — not an error, a hung promise — so `attachLoginIndicator()` loads about:blank first, is now async, and must be awaited before `loadURL`. `getNewToken()` awaits it, and treats a window closed while it happens as the abort it is. - It reaches the top-level document and any frame in its process, but not a cross-origin iframe, which gets its own CDP target. The `dom-ready` injection stays as the fallback for those, and for a debugger that could not attach. `npm run check:overlay` is the regression test: it drives the real `attachLoginIndicator()` on a real BrowserWindow against pages that ask for a key before and after `dom-ready`, and asserts the wait reached the main process. No security key needed — only the start of the request matters. It fails on the code before this commit and passes after, and CI runs it under xvfb, which the app turns out to run under perfectly well. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014s8Y8cKzE4bpyaxPMP19wi
The step name and the command say what it runs; the why belongs in AGENTS.md, where it already is. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014s8Y8cKzE4bpyaxPMP19wi
popen2
force-pushed
the
claude/aws-sso-yubikey-auth-pwu9m6
branch
from
August 30, 2026 09:35
6143f97 to
1b88211
Compare
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.
The overlay was injected on
dom-ready, which is after the page's own scriptshave run. A sign-in page that starts listening for the security key as it boots
— Google's 2SV challenge does exactly that — has already called
navigator.credentials.get()by then, so wrappingnavigator.credentialsafterwards wrapped nothing: no toast, no window title, no dock bounce, no log
line. An AWS SSO login backed by Google showed the user the same silent,
apparently-hung window as before issue #17 was fixed.
Register the overlay through the WebContents debugger instead, with
Page.addScriptToEvaluateOnNewDocument, so it runs at document start in thepage's own world — before any script the page ships, and again on the
cross-origin hop from AWS to the identity provider, which moves the page to a
different renderer process. Three details all fail silently and are spelled out
where they live:
Page.enablehas to come first. Without it the registration resolves anddoes nothing.
anything the command never resolves — not an error, a hung promise — so
attachLoginIndicator()loads about:blank first, is now async, and must beawaited before
loadURL.getNewToken()awaits it, and treats a windowclosed while it happens as the abort it is.
cross-origin iframe, which gets its own CDP target. The
dom-readyinjectionstays as the fallback for those, and for a debugger that could not attach.
npm run check:overlayis the regression test: it drives the realattachLoginIndicator()on a real BrowserWindow against pages that ask for akey before and after
dom-ready, and asserts the wait reached the mainprocess. No security key needed — only the start of the request matters. It
fails on the code before this commit and passes after, and CI runs it under
xvfb, which the app turns out to run under perfectly well.
Co-Authored-By: Claude Opus 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_014s8Y8cKzE4bpyaxPMP19wi