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
{{ message }}
Repository navigation
Commit 70a6432
Browse filesBrowse the repository at this point in the historyBrowse files
fix(electron,ui): Don't run passkey autofill as a modal prompt
The Electron passkey provider reported autofill as supported but serviced the
request as a modal ceremony, so an OS passkey sheet opened as soon as the sign-in
form mounted, before any user intent.
- `get()` now honours `conditionalUI` instead of hardcoding it to `false`, so the
renderer path performs real conditional mediation. When a conditional request
would resolve to the native or unsupported path it is quietly aborted rather
than prompting, and it no longer falls back to the native path on error.
- `isSupported()` and `isAutoFillSupported()` now answer through the same routing
rules as `decidePath()`, so they stop advertising capabilities the resolved path
cannot deliver.
- `SignInStart` resolves both WebAuthn predicates against the Clerk instance
before falling back to the shared helpers, so a host-provided passkey provider
can influence whether the autofill flow starts at all.
Closes#9496
Stop passkey autofill from opening a passkey prompt as soon as the sign-in form renders. Autofill now runs as a real background request when the window can service one (an `https` origin matching your RP ID), and is not attempted at all when it would route to the OS passkey dialog. Signing in with the explicit "Use passkey" action is unchanged.
Copy file name to clipboardExpand all lines: packages/electron/README.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -212,6 +212,8 @@ Passkey support works in two modes, selected automatically per request:
212
212
-**Renderer mode**: when your window loads content over `https://` from an origin that matches your passkey RP (Relying Party) ID, the renderer's built-in Chromium WebAuthn is used. Credentials are synced by the OS/browser ecosystem (Windows Hello works out of the box; Touch ID on macOS requires Electron ≥ 42 and [`app.configureWebAuthn`](https://www.electronjs.org/docs/latest/api/app#appconfigurewebauthnoptions-macos)).
213
213
-**Native mode**: when your window loads a local bundle (e.g. `scheme://host`), WebAuthn's origin checks reject the request, so the ceremony is routed over IPC to the main process and serviced by the OS WebAuthn APIs (AuthenticationServices on macOS, `webauthn.dll` on Windows) via the optional [`@clerk/electron-passkeys`](https://github.com/clerk/javascript/tree/main/packages/electron-passkeys) native module.
214
214
215
+
Passkey autofill relies on WebAuthn conditional mediation, which only the renderer can provide. In native mode passkeys are offered through the explicit "Use passkey" action instead; the sign-in form never opens a passkey prompt on its own.
0 commit comments