Skip to content

Show the credential overlay when the page asks for the key as it loads - #87

Merged
popen2 merged 2 commits into
mainfrom
claude/aws-sso-yubikey-auth-pwu9m6
Aug 30, 2026
Merged

Show the credential overlay when the page asks for the key as it loads#87
popen2 merged 2 commits into
mainfrom
claude/aws-sso-yubikey-auth-pwu9m6

Conversation

@popen2

@popen2 popen2 commented Aug 21, 2026

Copy link
Copy Markdown
Owner

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

@popen2
popen2 enabled auto-merge August 21, 2026 13:40
popen2 and others added 2 commits August 30, 2026 09:33
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
popen2 force-pushed the claude/aws-sso-yubikey-auth-pwu9m6 branch from 6143f97 to 1b88211 Compare August 30, 2026 09:35
@popen2
popen2 merged commit c378f9b into main Aug 30, 2026
9 checks passed
@popen2
popen2 deleted the claude/aws-sso-yubikey-auth-pwu9m6 branch August 30, 2026 09:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant