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.13.0

Minor Changes

• 3d64c6b: Answer 401, not 400, when nobody is signed in.

  ensureCookies gates every access-required route. When the required cookie was
  absent and there was no refresh cookie to fall back on, which is exactly the
  signed-out case, it answered 400. The request was perfectly well formed. There
  was simply no session, and that is what 401 means.

  This is a behaviour change for adopters. Anything branching on 400 from an
  /auth route to detect a malformed request will now see 401 for a signed-out
  visitor instead.

  Two things went wrong with the old status. Every signed-out page view produced
  400s, so 400 became ordinary background traffic in adopter logs and would
  hide a real malformed request from anyone watching. And consumers translate
  status codes into words for readers: 400 asks a product to say "that request
  did not come through in a form we could use" when the true sentence is "you have
  been signed out, sign in again".

  The neighbouring branches in the same function already answered 401 for a
  refresh that failed and for a cookie that was invalid or expired, so this branch
  was the outlier rather than the convention. All three now agree, and the status
  no longer depends on which way the session happened to be absent. The response
  body is unchanged.

• fb5c039: Forward a magic link destination to the auth API.

  seamless-auth-api now accepts an optional redirectUri on GET /magic-link,
  deciding where the emailed link lands. Until now the adapters called that route with
  no query, so the feature was reachable only by a backend calling the API directly. A
  browser or mobile client could not use it, which was most of the point: a tenant with
  both a web app and a mobile app needs each to receive a link that opens in the right
  place.

  RequestMagicLinkInput gains an optional redirectUri, and both adapters read it
  from the request body of their own POST /magic-link and pass it through. Omit it and
  nothing changes: the upstream URL is exactly what it was, so no adopter has to do
  anything.

  The adapters forward the value rather than checking it. The auth API validates it
  against the configured origins and answers 400 if it is not allowed, and an
  allowlist that lives in two places is one that eventually disagrees with itself. A
  value that is not a string is dropped rather than coerced, so it cannot turn into a
  query parameter meaning something the caller did not send.

  Requires an auth API that understands the parameter. Against an older one the
  parameter is ignored and the link keeps the tenant-wide destination, which is the
  behaviour adopters have today.

@seamless-auth/express@0.13.0

Minor Changes

• fb5c039: Forward a magic link destination to the auth API.

  seamless-auth-api now accepts an optional redirectUri on GET /magic-link,
  deciding where the emailed link lands. Until now the adapters called that route with
  no query, so the feature was reachable only by a backend calling the API directly. A
  browser or mobile client could not use it, which was most of the point: a tenant with
  both a web app and a mobile app needs each to receive a link that opens in the right
  place.

  RequestMagicLinkInput gains an optional redirectUri, and both adapters read it
  from the request body of their own POST /magic-link and pass it through. Omit it and
  nothing changes: the upstream URL is exactly what it was, so no adopter has to do
  anything.

  The adapters forward the value rather than checking it. The auth API validates it
  against the configured origins and answers 400 if it is not allowed, and an
  allowlist that lives in two places is one that eventually disagrees with itself. A
  value that is not a string is dropped rather than coerced, so it cannot turn into a
  query parameter meaning something the caller did not send.

  Requires an auth API that understands the parameter. Against an older one the
  parameter is ignored and the link keeps the tenant-wide destination, which is the
  behaviour adopters have today.

Patch Changes

• Updated dependencies [3d64c6b]
• Updated dependencies [fb5c039]
  • @seamless-auth/core@0.13.0

@seamless-auth/fastify@0.4.0

Minor Changes

• fb5c039: Forward a magic link destination to the auth API.

  seamless-auth-api now accepts an optional redirectUri on GET /magic-link,
  deciding where the emailed link lands. Until now the adapters called that route with
  no query, so the feature was reachable only by a backend calling the API directly. A
  browser or mobile client could not use it, which was most of the point: a tenant with
  both a web app and a mobile app needs each to receive a link that opens in the right
  place.

  RequestMagicLinkInput gains an optional redirectUri, and both adapters read it
  from the request body of their own POST /magic-link and pass it through. Omit it and
  nothing changes: the upstream URL is exactly what it was, so no adopter has to do
  anything.

  The adapters forward the value rather than checking it. The auth API validates it
  against the configured origins and answers 400 if it is not allowed, and an
  allowlist that lives in two places is one that eventually disagrees with itself. A
  value that is not a string is dropped rather than coerced, so it cannot turn into a
  query parameter meaning something the caller did not send.

  Requires an auth API that understands the parameter. Against an older one the
  parameter is ignored and the link keeps the tenant-wide destination, which is the
  behaviour adopters have today.

Patch Changes

• Updated dependencies [3d64c6b]
• Updated dependencies [fb5c039]
  • @seamless-auth/core@0.13.0