Version Packages - #134
Open
github-actions[bot] wants to merge 1 commit into
Open
Conversation
github-actions
Bot
force-pushed
the
changeset-release/main
branch
2 times, most recently
from
August 30, 2026 22:02
ad8959a to
8149584
Compare
github-actions
Bot
force-pushed
the
changeset-release/main
branch
from
August 31, 2026 15:01
8149584 to
fef875b
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.
This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.
Releases
@seamless-auth/react@0.10.0
Minor Changes
17a657d: Let a caller choose where a magic link lands.
requestMagicLinktakes an optionalredirectUri. A deployment serving both a webapp and a mobile app previously had one destination for every magic link, so a link
had to arrive in one or the other.
The value goes in the request body the client already sends. The deployment validates
it against its configured origins and refuses anything else, so this cannot be used to
point a link on the tenant's domain somewhere it should not go, and a refusal comes
back as an ordinary error result.
Omit it and nothing changes: the same empty body is sent, so the destination stays the
deployment's own and no caller has to do anything.
Needs a
@seamless-auth/serveradapter that forwards the field and an auth API thatunderstands it. Against older versions the value is dropped and the link keeps the
deployment's destination, which is the behaviour today.
4199d52: Add
getPasskeyPolicyErrorCode(), which reads the code a refused passkeyregistration carries (
attachment_not_allowed,synced_passkey_not_allowed,authenticator_not_allowed, orprf_required) so an app can explain therefusal instead of rendering the raw code from
error.message. Unrecognizedcodes return
undefined, so a refusal from a newer API keeps your genericmessaging.
The
PasskeyPolicyErrorCodeunion is derived fromWebAuthnErrorCodein@seamless-auth/types, so the codes this recognizes cannot drift from the onesthe API sends.
This matters on a default deployment: the API's
authenticator_policy.syncedPasskeysdefaults toblock, and passkeys createdby iCloud Keychain or Google Password Manager are backup eligible, so the most
common consumer passkey is refused at registration.
fa27861:
registerPasskey()accepts anattachment, so a caller can ask for a roamingauthenticator (
cross-platform, a USB or NFC security key) or the one builtinto the device (
platform) instead of leaving the choice to the browser'spicker. The bundled enrolment view offers a "Use a security key instead" control
that takes this path, and explains a policy refusal rather than showing a
generic failure.
Omitting the option sends no query parameter, so the deployment's
authenticator_policy.attachmentstays in charge and current behaviour isunchanged. It is a request rather than an override: a deployment that pins the
other kind refuses the registration with
attachment_not_allowed, whichgetPasskeyPolicyErrorCode()reads.PasskeyAttachmentis exported, and is derived from the deployment policy typein
@seamless-auth/typesrather than restating its members.