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
System Configuration says blocking synced passkeys is the shipped default, but the API now ships allow #255
src/pages/SystemConfig.tsx tells operators that blocking synced passkeys is what the auth API
ships by default. It is not, and has not been since the API reversed the default.
Line 791, in the banner shown when the policy is set to block:
Registration refuses any backup-eligible credential, which is most consumer passkeys: iCloud
Keychain, Google Password Manager, and similar. This is the shipped default. Allow them if
your users enrol from a platform password manager.
The last claim is stale. seamless-auth-api seeds authenticator_policy with syncedPasskeys: 'allow' (src/config/systemConfig.defaults.ts), changed in fells-code/seamless-auth-api#260. A stock install allows synced passkeys.
Line 80 has the matching problem in code rather than copy: the local fallback policy this page
falls back to is syncedPasskeys: "block", so a deployment that has not yet persisted the key
renders a page that disagrees with what the API would actually enforce.
Why it happens
This repo pins @seamless-auth/types at ^0.18.0, and the shared schema defaulted syncedPasskeys to block up to and including 0.18.0. The API carries an explicit note about
this in systemConfig.defaults.ts: it parses the value rather than restating it, and names syncedPasskeys specifically so the right value is seeded on either version of the types package,
to be dropped once its floor is 0.19.0.
So the page is not wrong about 0.18.0. It is wrong about what tenants are running.
Why it matters
This is the more consequential direction for the copy to be wrong in. An operator reading
"this is the shipped default" concludes their deployment already refuses iCloud Keychain and
Google Password Manager credentials, when a stock install accepts them. Someone who wants them
blocked may believe the work is done and never set the policy.
The v0.6.0 changelog entry for this section carries the same claim, describing the gap as
operationally significant because syncedPasskeys "now defaults to block". Worth correcting
there too if that text is reused anywhere.
Suggested fix
Drop "This is the shipped default." from the block banner, or restate it accurately.
Reconsider the block fallback at line 80 so the page's fallback matches the API's seed.
Raise the @seamless-auth/types pin past 0.19.0 so the schema default and the API agree, which
removes the underlying cause rather than just the sentence.
Activity