chore(deps): move the starters onto the session-gated enrolment release - #86
Merged
Merged
Conversation
@seamless-auth/react 0.11.0 to 0.12.0 in both React starters, @seamless-auth/express 0.13.0 to 0.14.0, and @seamless-auth/fastify 0.4.0 to 0.5.0. The three are one release: the WebAuthn register routes now read the access session rather than the ephemeral token the auth API mints from an email address alone. The API stopped accepting that token in 0.11.0 and there is no safe order between the sides, so enrolment answers 401 until both land. The starters needed the version and nothing else.
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
1 participant
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.
Moves the starters onto the auth packages published today, which put passkey enrolment behind a signed-in session.
@seamless-auth/react@seamless-auth/express@seamless-auth/fastifyWhy the three move together
/webAuthn/register/startand/webAuthn/register/finishused to accept the ephemeral token the auth API mints from an email address alone, so anyone who knew an address could enrol a credential against that account and sign in as its owner. Both routes now read the access session instead.seamless-auth-apistopped accepting the old token in 0.11.0, and there is no safe release order between the two sides: an older adapter sends what the API refuses, and these adapters send what an older API refuses, so enrolment answers 401 until both have landed. A project scaffolded from this tag should point atseamless-auth-api0.12.0, the current release.No shipped flow loses a step. Registration proves an address with an email OTP and verifying it issues a session, so the client already holds one by the time the passkey screen appears.
What changed here
Four
package.jsonversions and their lockfiles, plus a changeset. Nothing else.createSeamlessAuthServer,requireAuth,requireRoleandSeamlessAuthUserare unchanged, and the adapters' other work in 0.14.0 and 0.5.0 is route plumbing behind them (aDELETE /admin/organizations/:organizationIdproxy, and the query string restored onGET /admin/usersand the login-stats endpoint). The React additions are optional, so no starter source moves.Lockfile churn is limited to the seamless packages:
@seamless-auth/corefollows the adapters to 0.14.0, and@seamless-auth/typeswas already at 0.20.0 from #84.Follows #84, which took the same starters from react 0.9.0, express 0.12.0 and fastify 0.3.1 to the versions this builds on.
Verification
Each of the four templates was installed fresh and run the way the release PR's matrix will:
npm run checknpm run buildRoot
npm run validateandnpm run format:checkpass.These are the starters' own gates, so they prove the templates compile and their tests hold against the new packages. They do not exercise enrolment against a running auth API, which is what the lockstep note above is about.