Version Packages

[github-actions]

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/core@0.14.0

Minor Changes

• 9e9afb2: Forward the query string on the two routes that dropped it.

  GET /admin/users and GET /internal/auth-events/login-stats were built without
  a query, so both adapters called the auth API with a bare path. Every other route
  that reads query parameters forwarded them, which is what made these two hard to
  notice: the endpoints answered 200 with the wrong page or the wrong window, and
  nothing reported an error.

  The visible effect was that the admin dashboard's user search and paging did
  nothing. It sent ?search=...&limit=10&offset=N, the adapter forwarded
  /admin/users, and the API answered with its default first 50 users. The login
  statistics panel ignored its time range the same way, so the range control on the
  Security screen moved the other panels and not that one.

  getUsersHandler and getLoginStatsHandler in @seamless-auth/core now take an
  optional query like the other list handlers. The change is additive for anyone
  calling them directly, and both adapters pass the incoming query through.

  Adopters should expect requests to start reaching the API as sent. A caller that
  was relying on the dropped window will now get the page it actually asked for
  rather than the API's default, and a query the API rejects now surfaces as a
  400 instead of being silently discarded.

  Both adapters are now held to one table of every query-carrying route, so a route
  added without forwarding its query fails a test rather than shipping quiet.

• 485f37b: Passkey enrollment now forwards the access session. This is a coordinated contract
  change with seamless-auth-api, which refuses a pre-auth token on these routes as of the
  matching release.

  /webAuthn/register/start and /webAuthn/register/finish read the registration cookie
  and sent the ephemeral token upstream. The auth API mints one of those for an account
  that already exists, from an email address alone, so anyone who knew an address could
  enroll a credential against the account and sign in as its owner. Both routes now read
  the access cookie and forward the access token. /webAuthn/login/start and
  /webAuthn/login/finish are unchanged and still take the pre-auth cookie, because
  authenticating is what they are for.

  No shipped flow loses a step. Registration proves an address with an email OTP, and
  verifying it issues a session, so the client holds an access cookie by the time it offers
  a passkey. An application that offered enrollment before verifying an address has to move
  that step after it.

  Upgrade this and the auth API together. There is no safe order between them: an older
  adapter sends the token the new API refuses, and this release sends one an older API
  refuses, so enrollment answers 401 until both sides land.

  finishRegisterHandler no longer issues session cookies. Enrolling a passkey is not a
  sign-in, and the caller now arrives holding a session, so minting a second one left the
  first live and unrevoked while counting against the API's concurrent session limit, which
  can evict the user's other devices. The route still answers 204.

  FinishRegisterOptions drops audience, cookieDomain, accessCookieName and
  refreshCookieName, and FinishRegisterResult drops setCookies. Only the two adapters
  in this workspace passed them, and both are updated. Code calling
  finishRegisterHandler directly should pass { authServerUrl } alone.

  This does not change the pre-auth routes' silent refresh, which still mints an access
  token into a cookie those routes cannot use. That is tracked separately.

@seamless-auth/express@0.14.0

Minor Changes

• ef5989f: Pass DELETE /admin/organizations/:organizationId through to the auth API.

  The auth API gained an organization delete route, and neither adapter forwarded it,
  so a dashboard or backend calling through the adapter got a 404 from the adapter's
  own router rather than reaching the API at all. Both adapters now proxy it with the
  access identity, the same way the neighbouring organization routes are proxied.

  GET /admin/organizations needed no adapter change. Both adapters already forward
  the query string, so the limit, offset and search parameters the API added
  alongside the delete route reach it without one.

  Requires an auth API that serves the route. Calling it against an older API returns
  that API's 404, so the adapters can ship first and there is no lockstep requirement
  in either direction.

• 9e9afb2: Forward the query string on the two routes that dropped it.

  GET /admin/users and GET /internal/auth-events/login-stats were built without
  a query, so both adapters called the auth API with a bare path. Every other route
  that reads query parameters forwarded them, which is what made these two hard to
  notice: the endpoints answered 200 with the wrong page or the wrong window, and
  nothing reported an error.

  The visible effect was that the admin dashboard's user search and paging did
  nothing. It sent ?search=...&limit=10&offset=N, the adapter forwarded
  /admin/users, and the API answered with its default first 50 users. The login
  statistics panel ignored its time range the same way, so the range control on the
  Security screen moved the other panels and not that one.

  getUsersHandler and getLoginStatsHandler in @seamless-auth/core now take an
  optional query like the other list handlers. The change is additive for anyone
  calling them directly, and both adapters pass the incoming query through.

  Adopters should expect requests to start reaching the API as sent. A caller that
  was relying on the dropped window will now get the page it actually asked for
  rather than the API's default, and a query the API rejects now surfaces as a
  400 instead of being silently discarded.

  Both adapters are now held to one table of every query-carrying route, so a route
  added without forwarding its query fails a test rather than shipping quiet.

• 485f37b: Passkey enrollment now forwards the access session. This is a coordinated contract
  change with seamless-auth-api, which refuses a pre-auth token on these routes as of the
  matching release.

  /webAuthn/register/start and /webAuthn/register/finish read the registration cookie
  and sent the ephemeral token upstream. The auth API mints one of those for an account
  that already exists, from an email address alone, so anyone who knew an address could
  enroll a credential against the account and sign in as its owner. Both routes now read
  the access cookie and forward the access token. /webAuthn/login/start and
  /webAuthn/login/finish are unchanged and still take the pre-auth cookie, because
  authenticating is what they are for.

  No shipped flow loses a step. Registration proves an address with an email OTP, and
  verifying it issues a session, so the client holds an access cookie by the time it offers
  a passkey. An application that offered enrollment before verifying an address has to move
  that step after it.

  Upgrade this and the auth API together. There is no safe order between them: an older
  adapter sends the token the new API refuses, and this release sends one an older API
  refuses, so enrollment answers 401 until both sides land.

  finishRegisterHandler no longer issues session cookies. Enrolling a passkey is not a
  sign-in, and the caller now arrives holding a session, so minting a second one left the
  first live and unrevoked while counting against the API's concurrent session limit, which
  can evict the user's other devices. The route still answers 204.

  FinishRegisterOptions drops audience, cookieDomain, accessCookieName and
  refreshCookieName, and FinishRegisterResult drops setCookies. Only the two adapters
  in this workspace passed them, and both are updated. Code calling
  finishRegisterHandler directly should pass { authServerUrl } alone.

  This does not change the pre-auth routes' silent refresh, which still mints an access
  token into a cookie those routes cannot use. That is tracked separately.

Patch Changes

• Updated dependencies [9e9afb2]
• Updated dependencies [485f37b]
  • @seamless-auth/core@0.14.0

@seamless-auth/fastify@0.5.0

Minor Changes

• ef5989f: Pass DELETE /admin/organizations/:organizationId through to the auth API.

  The auth API gained an organization delete route, and neither adapter forwarded it,
  so a dashboard or backend calling through the adapter got a 404 from the adapter's
  own router rather than reaching the API at all. Both adapters now proxy it with the
  access identity, the same way the neighbouring organization routes are proxied.

  GET /admin/organizations needed no adapter change. Both adapters already forward
  the query string, so the limit, offset and search parameters the API added
  alongside the delete route reach it without one.

  Requires an auth API that serves the route. Calling it against an older API returns
  that API's 404, so the adapters can ship first and there is no lockstep requirement
  in either direction.

• 9e9afb2: Forward the query string on the two routes that dropped it.

  GET /admin/users and GET /internal/auth-events/login-stats were built without
  a query, so both adapters called the auth API with a bare path. Every other route
  that reads query parameters forwarded them, which is what made these two hard to
  notice: the endpoints answered 200 with the wrong page or the wrong window, and
  nothing reported an error.

  The visible effect was that the admin dashboard's user search and paging did
  nothing. It sent ?search=...&limit=10&offset=N, the adapter forwarded
  /admin/users, and the API answered with its default first 50 users. The login
  statistics panel ignored its time range the same way, so the range control on the
  Security screen moved the other panels and not that one.

  getUsersHandler and getLoginStatsHandler in @seamless-auth/core now take an
  optional query like the other list handlers. The change is additive for anyone
  calling them directly, and both adapters pass the incoming query through.

  Adopters should expect requests to start reaching the API as sent. A caller that
  was relying on the dropped window will now get the page it actually asked for
  rather than the API's default, and a query the API rejects now surfaces as a
  400 instead of being silently discarded.

  Both adapters are now held to one table of every query-carrying route, so a route
  added without forwarding its query fails a test rather than shipping quiet.

• 485f37b: Passkey enrollment now forwards the access session. This is a coordinated contract
  change with seamless-auth-api, which refuses a pre-auth token on these routes as of the
  matching release.

  /webAuthn/register/start and /webAuthn/register/finish read the registration cookie
  and sent the ephemeral token upstream. The auth API mints one of those for an account
  that already exists, from an email address alone, so anyone who knew an address could
  enroll a credential against the account and sign in as its owner. Both routes now read
  the access cookie and forward the access token. /webAuthn/login/start and
  /webAuthn/login/finish are unchanged and still take the pre-auth cookie, because
  authenticating is what they are for.

  No shipped flow loses a step. Registration proves an address with an email OTP, and
  verifying it issues a session, so the client holds an access cookie by the time it offers
  a passkey. An application that offered enrollment before verifying an address has to move
  that step after it.

  Upgrade this and the auth API together. There is no safe order between them: an older
  adapter sends the token the new API refuses, and this release sends one an older API
  refuses, so enrollment answers 401 until both sides land.

  finishRegisterHandler no longer issues session cookies. Enrolling a passkey is not a
  sign-in, and the caller now arrives holding a session, so minting a second one left the
  first live and unrevoked while counting against the API's concurrent session limit, which
  can evict the user's other devices. The route still answers 204.

  FinishRegisterOptions drops audience, cookieDomain, accessCookieName and
  refreshCookieName, and FinishRegisterResult drops setCookies. Only the two adapters
  in this workspace passed them, and both are updated. Code calling
  finishRegisterHandler directly should pass { authServerUrl } alone.

  This does not change the pre-auth routes' silent refresh, which still mints an access
  token into a cookie those routes cannot use. That is tracked separately.

Patch Changes

• Updated dependencies [9e9afb2]
• Updated dependencies [485f37b]
  • @seamless-auth/core@0.14.0