chore: bump to auth API v0.12.0, dashboard v0.6.0, templates v0.13.0 - #200
Merged
Conversation
v0.11.0 puts passkey enrollment behind an access session, a breaking wire contract change: the API refuses the pre-auth token enrollment used to accept, so an ephemeral token can no longer enroll a credential against an account and then sign in as its owner. It also declares and validates the window on GET /admin/users, and adds organization deletion with a paged, searchable admin organization list. v0.12.0 ships dashboard v0.6.0 in the API image, so the dashboard pin moves with it and the standalone console serves the same release the image serves at /console. The conformance adapters move to @seamless-auth/express ^0.14.0 and @seamless-auth/fastify ^0.5.0, the other half of the enrollment change: they forward the access session the API now requires. They also proxy the organization delete, and forward the query string on GET /admin/users and GET /internal/auth-events/login-stats, which both dropped it. SEAMLESS_TEMPLATES_REF stays at v0.12.0. Its API starters pin the adapters from before the enrollment change and a caret on a 0.x version cannot reach 0.14.0 or 0.5.0, so a project scaffolded against this release runs a new API behind an old adapter and passkey enrollment answers 401 until templates publishes with the new pins and the ref follows. Email OTP and magic link sign-in are unaffected. The harness pins its own adapters, so it exercises the matched pair and will not show this.
Templates v0.13.0 published after the previous commit and carries the matched half of the enrollment change: @seamless-auth/react 0.12.0, @seamless-auth/express 0.14.0 and @seamless-auth/fastify 0.5.0 in the starters. Its own notes say to point a scaffolded project at seamless-auth-api 0.12.0, which is what this branch pins. That closes the gap the previous commit documented. A scaffold no longer runs a new API behind an adapter from before the contract change, so passkey enrollment works out of the box and the changeset drops the caveat. The manifest contract and the registry are byte-identical to v0.12.0, so nothing in init moves with the ref.
Bccorb
changed the title
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.
SEAMLESS_AUTH_API_VERSIONSEAMLESS_AUTH_ADMIN_DASHBOARD_VERSIONSEAMLESS_TEMPLATES_REF@seamless-auth/express(verify adapter)@seamless-auth/fastify(verify adapter)The enrollment change, and why everything moves at once
API
v0.11.0puts passkey enrollment behind an access session./webAuthn/register/startand/webAuthn/register/finishused to accept the ephemeral token the API mints from an email address alone, so anyone who knew an address could enroll a credential against that account and sign in as its owner. Both routes read the access session now, and enrollment no longer issues a session of its own.There is no safe release order between the API and the adapter — an older adapter sends what the new API refuses, and a newer adapter sends what an older API refuses, so enrollment answers
401until both land. This branch therefore moves every side together:v0.12.0,v0.13.0, which carries@seamless-auth/react0.12.0,@seamless-auth/express0.14.0and@seamless-auth/fastify0.5.0,^0.14.0/^0.5.0.No shipped flow loses a step: registration proves an address with an email OTP, and verifying it issues the session before the passkey screen appears.
Auth API
v0.11.0also declares and validates the window onGET /admin/users—limit1–100,offsetfrom 0,searchtrimmed — so it appears inopenapi.jsonalongside the other admin collections, and addsDELETE /admin/organizations/:organizationIdwith a paged, searchable organization list. The CLI side of that window landed separately in #199.v0.12.0ships dashboardv0.6.0inside the API image..env.exampleis byte-identical between v0.10.0 and v0.12.0, so no new scaffold environment keys arrive with this.Admin dashboard
v0.6.0pages and searches organizations on the server rather than filtering loaded rows in memory, gains a Remove action behind step-up, takes a date range on Overview and Security, and grows an Authenticator Policy section. Bumping the constant keeps the standalone console (--admin=image,--admin=source) on the release the API image now serves at/console.Adapters
Beyond forwarding the access session,
express0.14.0/fastify0.5.0proxy the organization delete, and forward the query string onGET /admin/usersandGET /internal/auth-events/login-stats— both were built without one, so the dashboard's user search and its login statistics range were silently answered with the API's defaults.Verification
v0.12.0image actually exists on GHCR before pinning: it was still building when this work started (manifest404), and the pin was applied only after itsPublish versioned imagejob finished and the manifest returned200. Dashboardv0.6.0returns200too.registry.jsonfetches200at templatesv0.13.0, and everytemplate.jsonplus the registry is byte-identical to v0.12.0, so nothing ininitmoves with the ref.npm viewresolves^0.14.0/^0.5.0to 0.14.0 and 0.5.0..env.exampleat v0.12.0 — keys reach the generated compose correctly escaped.npm run buildpasses; 1001 tests pass, 4 skipped.seamless verifyneeds Docker and sibling checkouts, so the released-mode conformance run against API v0.12.0 and the 0.14.0 / 0.5.0 adapters is CI'sverify-conformancejob on this PR.