Version Packages

packages/core/CHANGELOG.md

@@ -1,5 +1,57 @@
 # @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
+  `400`s, 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.
+
 ## 0.12.1
 
 ### Patch Changes

packages/core/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@seamless-auth/core",
-    "version": "0.12.1",
+    "version": "0.13.0",
     "description": "Framework-agnostic core authentication logic for SeamlessAuth",
     "keywords": [
         "authentication",

packages/express/CHANGELOG.md

@@ -1,5 +1,39 @@
 # @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
+
 ## 0.12.1
 
 ### Patch Changes

packages/express/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@seamless-auth/express",
-  "version": "0.12.1",
+  "version": "0.13.0",
   "description": "Express adapter for Seamless Auth passwordless authentication",
   "keywords": [
     "authentication",

packages/fastify/CHANGELOG.md

@@ -1,5 +1,39 @@
 # @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
+
 ## 0.3.1
 
 ### Patch Changes

packages/fastify/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@seamless-auth/fastify",
-  "version": "0.3.1",
+  "version": "0.4.0",
   "description": "Fastify adapter for Seamless Auth passwordless authentication",
   "keywords": [
     "authentication",