@nxgt/janus 0.24.0 → 0.26.0

package/dist/permissions/index.js

@@ -4,16 +4,16 @@ import {
   UNSTORABLE,
   MAX_PAGE_SIZE2,
   pageLimit2
-} from "../chunks/index-4khsm7mw.js";
+} from "../chunks/index-y9b327j8.js";
 import {
   PermissionDepthError2,
   isSubjectSet2,
   isSetOf2,
   formatEntity2
-} from "../chunks/index-kppkcbn5.js";
+} from "../chunks/index-spwh8b9z.js";
 import {
   createMemoryRelations2
-} from "../chunks/index-cntabs9d.js";
+} from "../chunks/index-rpp0bw6e.js";
 
 // src/permissions/resolve/resolved.ts
 function admits(holders, subject) {

package/docs/guide/adapters.md

@@ -31,7 +31,7 @@ describeJanusStores({
 
 | Port | Taken by | Methods |
 | --- | --- | --- |
-| `JanusStores` — `{ users: UserStore, sessions: SessionStore, tokens: TokenStore }` | `janus({ store })` | 6 (+ 1 optional) + 7 (+ 1 optional) + 5 |
+| `JanusStores` — `{ users: UserStore, sessions: SessionStore, tokens: TokenStore }` | `janus({ store })` | 6 (+ 1 optional) + 7 (+ 1 optional) + 5 (+ 1 optional) |
 | `RelationStore` | `permissions({ store })`, `janus({ relations })` | 6 |
 
 They are separate on purpose: an application that only authenticates
@@ -184,6 +184,7 @@ interface TokenStore {
 	countAttempt(tokenHash: string, kind: TokenKind): Promise<TokenRecord | null>;
 	spendUserTokens(userId: Id, kind: TokenKind, at: Date, except?: string): Promise<number>; // the unspent ones, but except
 	deleteUserTokens(userId: Id): Promise<number>;
+	deleteExpiredTokens?(before: Date): Promise<number>; // optional: omit it if the database expires on its own
 }
 ```
 
@@ -368,6 +369,41 @@ of the right `kind` whose `spentAt` is empty, skipping the one named by
 `except`. `spendUserTokens` has its own
 outage case.
 
+### `TokenStore.deleteExpiredTokens` (optional)
+
+What `collectExpired()` asks for, beside `SessionStore.deleteExpiredSessions`:
+**delete every token whose `expiresAt` is at or before `before`**, and answer
+how many. Leave it out when your database expires records on its own (a TTL
+index, a key TTL) — nothing breaks, the core compares `expiresAt` on every
+redemption — and implement it when it does not, or the rows pile up.
+
+| The stored token | Written |
+| --- | --- |
+| `expiresAt` at or before `before`, spent or not, of any kind and any user | deleted, and counted |
+| `expiresAt` later than `before`, spent or not | **kept** |
+| none at all | `0`, an absence — never a failure |
+
+**Never delete a token whose `expiresAt` is later, spent or not**: a spent
+token is kept, answered as spent, until it lapses, or a count would start
+over. That includes the throttles' counts — ordinary `secondFactor` tokens
+under a keyed-hash user id, which `deleteUserTokens` never reaches and this
+method is the only thing to collect. The core calls it with `clock.now()`, no
+margin: a link collected answers `TOKEN_UNKNOWN`.
+
+```ts
+import type { TokenStore } from '@nxgt/janus';
+
+// PostgreSQL through Drizzle — one statement, over an index on expires_at
+deleteExpiredTokens: async (before) =>
+	(await db.delete(tokens).where(lte(tokens.expiresAt, before)).returning({ tokenHash: tokens.tokenHash })).length,
+```
+
+`janus()` reads its presence once (`StoreCapabilities.collectExpiredTokens`),
+and refuses a `deleteExpiredTokens` that is there but not a function with a
+`TypeError`. The suite's `tokens.deleteExpired` and `outage.deleteExpiredTokens`
+cases check it, and are skipped with their reason for a store that leaves it
+out. A failure throws, as everywhere on the port.
+
 ### `RelationStore`
 
 ```ts
@@ -449,7 +485,7 @@ compile error naming the missing method.
 
 | Suite | Cases | Harness opens |
 | --- | --- | --- |
-| `describeJanusStores({ name, harness, runner?, faults?, skip? })` | 59: users, sessions, tokens, and one outage per method whose honest answer can be "nothing" — fifteen of them | `{ stores, faults?, close? }` |
+| `describeJanusStores({ name, harness, runner?, faults?, skip? })` | 61: users, sessions, tokens, and one outage per method whose honest answer can be "nothing" — sixteen of them | `{ stores, faults?, close? }` |
 | `describeRelationStores({ name, harness, runner?, faults?, skip? })` | 16: the relation store, ids of edge characters, and one outage per method | `{ store, faults?, close? }` |
 
 `harness.open()` is called **once per case** and must answer fresh, empty
@@ -546,7 +582,8 @@ describeJanusStores({
 
 A skipped case still appears in the run, with its reason in its name. A case
 that cannot run on the stores it was given — an outage case with no `faults`,
-`collectExpired` on a store without `deleteExpiredSessions`, a `findUsers`
+`sessions.deleteExpired` on a store without `deleteExpiredSessions`,
+`tokens.deleteExpired` on one without `deleteExpiredTokens`, a `findUsers`
 case on a store without `findUsers` — passes, and emits a
 `JANUS_CONFORMANCE_SKIPPED` warning with the reason. A case's `needs` says what
 it cannot run without — one `CaseNeed` or a list: `outage.findUsers` needs

package/docs/guide/email-flows.md

@@ -265,6 +265,20 @@ is no longer the one it was asked from although nothing spent it: a write
 outside janus, or a `send` racing an `update`. `confirm` sends `user.emailChanged` (with
 `formerEmail`) and `user.emailVerified`.
 
+**With several user types**, a type's own `confirm` answers `TOKEN_UNKNOWN`
+for a token issued to another type's user, and spends it — a later
+confirmation through the right type is then `TOKEN_SPENT`. A page that does
+not know the type calls the root's `confirm`, which reads the user the token
+was issued to and confirms as their type does: same move, same events, same
+errors, and `type` in the answer says which type it was. `send` stays on each
+type. The root's exists when one type has an e-mail, which is why no type may
+be named `changeEmail`.
+
+```ts
+// one anonymous page for every type
+const changed = await auth.changeEmail.confirm(token); // changed.type: 'admin' | 'member'
+```
+
 **Gate `send`, and tell the former address.** Whoever changes the e-mail
 takes over every reset: call `send` behind a fresh sign-in or a step-up.
 
@@ -511,8 +525,8 @@ answers again. A refused request is counted too but cannot extend the wait.
 **Where the counts live.** In the tokens store, as `secondFactor` tokens named
 by a keyed hash of the flow and the address or user id: no port change, no new
 infrastructure, and never the address. That is one row per flow per address or
-user per window. On PostgreSQL, `collectExpired()` does not collect lapsed
-ones: schedule the delete, as for the sign-in throttle. A flushed or evicting
+user per window. `collectExpired()` collects the lapsed ones on a tokens store that implements
+`deleteExpiredTokens`; a store with a TTL expires them on its own. A flushed or evicting
 Redis forgets the counts, and a tokens store that cannot count throws
 `STORE_FAILED` with nothing issued: it fails closed.
 

package/docs/guide/errors.md

@@ -64,7 +64,7 @@ that wired the library, so no handler needs to tell it apart.
 | `SECOND_FACTOR_NOT_ENROLLED` | `SecondFactorError` | 409 | `activate` before `enroll`; `regenerateRecoveryCodes` without an active factor; `confirm` or `recover` after the factor was disabled | `userId` |
 | `SECOND_FACTOR_ACTIVE` | `SecondFactorError` | 409 | `enroll` or `activate` on a factor already active: `disable` it first | `userId` |
 | `INVALID_CURSOR` | `InvalidCursorError` | 400 | A cursor this store did not mint. Never a silent first page | |
-| `UNSUPPORTED` | `UnsupportedError` | 501 | The wired store lacks an optional capability — `collectExpired` without `deleteExpiredSessions` | `slot`, `operation` |
+| `UNSUPPORTED` | `UnsupportedError` | 501 | The wired store lacks an optional capability — `collectExpired` with neither `deleteExpiredSessions` nor `deleteExpiredTokens` | `slot`, `operation` |
 | `PERMISSION_DEPTH` | `PermissionDepthError` | 500 | A check or list walked past `maxDepth`. **Not a denial** | `permission`, `maxDepth` |
 
 Every class extends `JanusError`, which extends `Error`, so no `catch` block

package/docs/guide/passwords.md

@@ -195,16 +195,13 @@ counts correctly. Each is named by a keyed hash of the login, never the login
 otherwise, which only keeps the login out of plain sight: a dump of the
 tokens then tells which logins were tried, for a guessed list. Each expires
 two windows after its window starts — half an hour by default — **Redis and MongoDB drop it then;
-PostgreSQL keeps it** until something deletes it, and every login tried,
-registered or not, adds a row per window. Schedule a delete with
-`@nxgt/janus-drizzle`:
-
-```sql
-delete from tokens where expires_at < now() - interval '1 hour'; -- janus.tokens when your tables have a schema of their own
-```
-
-`tokens` has no index on `expires_at`, so the delete scans the table: add
-`create index on tokens (expires_at)` in a migration of yours if it grows.
+a store with no TTL keeps it** until `collectExpired()` deletes it (the
+tokens store's optional `deleteExpiredTokens`), and every login tried,
+registered or not, adds a row per window. Schedule `collectExpired()` on such
+a store: `@nxgt/janus-drizzle` implements `deleteExpiredTokens` (since 0.9),
+with an index on `expires_at` that its
+[migration](https://github.com/softistx/nxgt-janus/blob/develop/packages/janus-drizzle/docs/guide/migrations.md#to-09-an-index-on-tokensexpires_at)
+adds. A store of your own implements the method, or its rows stay.
 
 The key is your first `secondFactor` key: wiring
 `secondFactor` for the first time, or putting a new key first, starts every

package/docs/guide/sessions.md

@@ -329,10 +329,21 @@ a link or a code already in the person's inbox still works afterwards.
 const removed: number = await auth.collectExpired();
 ```
 
-Deletes lapsed sessions, for a store that keeps them. It rejects with
-`UNSUPPORTED` when the sessions store does not implement the optional
-`deleteExpiredSessions` — a store with its own TTL, such as
-`@nxgt/janus-mongo`'s, does not. The reference store implements it.
+Deletes lapsed sessions and lapsed one-time tokens, from the stores that keep
+them, and answers how many in all. The tokens include the sign-in and mail
+throttles' counts, which are ordinary tokens. It runs whichever of the
+optional `sessions.deleteExpiredSessions` and `tokens.deleteExpiredTokens` the
+stores implement, sessions first, and rejects with `UNSUPPORTED` only when
+neither does — a store with its own TTL, such as `@nxgt/janus-mongo`'s, does
+not implement them. The reference store implements both.
+
+A token is deleted once its `expiresAt` is at or before now, spent or not;
+one that has not lapsed is never deleted, so a throttle keeps counting and a
+link still redeems until its time is up. After a token is collected, its link
+answers `TOKEN_UNKNOWN` rather than `TOKEN_EXPIRED` or `TOKEN_SPENT`, as it
+already does on a store with a TTL. A failure in the tokens store, after the
+sessions went, is `STORE_FAILED`; both deletions are idempotent, so call it
+again.
 
 ## Testing expiry
 

package/docs/guide/users.md

@@ -168,7 +168,7 @@ and `schemaVersion`, with the defaults above. A login is unique **per type**:
 the same e-mail may hold a patient user and a staff user. A type name is
 camelCase, and may not be one of `janus()`'s own methods (`authenticate`,
 `signOut`, `signOutEverywhere`, `findUser`, `getUser`, `cookie`,
-`collectExpired`, `types`) — a compile error, and a `TypeError` for a
+`collectExpired`, `types`, `changeEmail`) — a compile error, and a `TypeError` for a
 JavaScript caller.
 
 ## What each user type answers

package/docs/roadmap.md

@@ -5,7 +5,7 @@ dates here, and the version something shipped in is the only number.
 
 ## Now
 
-Nothing between releases.
+Nothing yet.
 
 ## Next
 
@@ -13,13 +13,6 @@ Nothing yet.
 
 ## Later
 
-- **Collecting lapsed one-time tokens** — `collectExpired()` deletes lapsed
-  sessions only. On a store with no TTL (PostgreSQL), lapsed tokens stay
-  until you delete them, and the sign-in throttle adds one per login tried
-  per window, and the mail throttle one per flow per address or user per
-  window. A port method to collect them, as sessions are, would let the
-  core do it.
-
 - **A batch read across types** — `findMany` reads one user type, as `find`
   does. The shared `findUser(id)` has no batch counterpart yet; one on the
   instance, answering a union narrowed by `user.type`, would serve a list that
@@ -76,6 +69,19 @@ Nothing yet.
 The last ten, newest first, each with the version it came in. Everything
 before is in the [CHANGELOG](../CHANGELOG.md).
 
+- **Root `changeEmail.confirm` for instances with several user types, v0.26.0** —
+  `auth.changeEmail.confirm(token)` confirms a change of e-mail for a page that
+  does not know the user's type: it reads the user the link was issued to and
+  confirms as their type does. A type's own `confirm` still answers
+  `TOKEN_UNKNOWN`, and spends the token, for another type's link; no user type
+  may be named `changeEmail`.
+- **Collecting lapsed one-time tokens, v0.25.0** — `collectExpired()` deletes
+  lapsed sessions and, through a new optional `TokenStore.deleteExpiredTokens`,
+  lapsed one-time tokens too: the sign-in and mail throttles' counts
+  included, which a store with no TTL (PostgreSQL) kept for ever, one per
+  login tried per window and one per flow per address or user per window.
+  The reference store and `@nxgt/janus-drizzle` 0.9 implement it; MongoDB and
+  Redis expire tokens themselves and do not.
 - **Finding a user, or creating them, v0.24.0** —
   `auth.<type>.findOrCreate(key, input)` answers `{ user, created }`: the
   holder of the key — the login on a type with a password, the e-mail on one
@@ -153,15 +159,3 @@ before is in the [CHANGELOG](../CHANGELOG.md).
   optional `findUsers`, implemented by the reference store,
   `@nxgt/janus-drizzle` 0.7.0 and `@nxgt/janus-mongo` 0.8.0; a store without it
   is read with `findUser`, ten at a time, so third-party adapters keep working.
-- **Requests that send e-mail are throttled, v0.18.0** —
-  `janus({ mail: { throttle: { attempts, window } } })`, five per ten
-  minutes by default and `false` to turn it off. `magicLink.request`,
-  `signInCode.request` and `resetPassword.request` count per address;
-  `verifyEmail.send` and an e-mailed `stepUp.request` count per user; each
-  flow on its own. Past the limit a request throws `MailThrottledError`
-  (`MAIL_THROTTLED`, 429) with `retryAfter` and issues, spends and rotates
-  nothing: the last link or code sent still works, so a loop on an address
-  cannot lock its owner out.
-  The window is no longer than the shortest default token lifetime. The counts
-  live in the tokens store, with no port change. `MailConfig` and
-  `MailThrottleConfig` are exported.

package/docs/troubleshooting.md

@@ -75,7 +75,7 @@ How the messages are shaped:
 - [`TOKEN_STALE` — `<call>: the token was sent to an e-mail the user no longer has`](#token_stale--call-the-token-was-sent-to-an-e-mail-the-user-no-longer-has)
 - [`INVALID_CURSOR` — `<call>: this cursor was not minted by this store …`](#invalid_cursor--call-this-cursor-was-not-minted-by-this-store-or-was-minted-for-another-ordering-n-characters)
 - [`<call>: limit must be an integer of at least 1, or absent`](#call-limit-must-be-an-integer-of-at-least-1-or-absent)
-- [`UNSUPPORTED` — `collectExpired: store.sessions does not implement deleteExpiredSessions …`](#unsupported--collectexpired-storesessions-does-not-implement-deleteexpiredsessions--its-store-expires-sessions-on-its-own-or-implement-the-method)
+- [`UNSUPPORTED` — `collectExpired: store.sessions does not implement deleteExpiredSessions, nor store.tokens deleteExpiredTokens …`](#unsupported--collectexpired-storesessions-does-not-implement-deleteexpiredsessions-nor-storetokens-deleteexpiredtokens--their-stores-expire-records-on-their-own-or-implement-the-methods)
 - [`<call>: the <type> type does not sign in with a password …`](#call-the-type-type-does-not-sign-in-with-a-password--add-password--login--to-it)
 - [`authenticate()` answers `null` although a valid cookie was sent](#authenticate-answers-null-although-a-valid-cookie-was-sent)
 
@@ -297,10 +297,10 @@ janus({ ..., hasher: scryptHasher(), verifiers: [legacyBcrypt] }); // not [scryp
 
 ### `janus: store.<slot> has no method <method>, which the port requires`
 
-Also: `janus: store.<slot> is missing`, `janus: store must be an object with users, sessions and tokens`, `janus: store.sessions.deleteExpiredSessions must be a function or absent`, `janus: store.users.findUsers must be a function or absent`.
+Also: `janus: store.<slot> is missing`, `janus: store must be an object with users, sessions and tokens`, `janus: store.sessions.deleteExpiredSessions must be a function or absent`, `janus: store.tokens.deleteExpiredTokens must be a function or absent`, `janus: store.users.findUsers must be a function or absent`.
 
 **When:** `janus({...})`, from JavaScript or with a store typed loosely. TypeScript refuses a partial store at compile time and names the method.
-**Why:** `store` is `{ users, sessions, tokens }`, and each slot must answer every method of the port. Two methods are optional — `sessions.deleteExpiredSessions` and `users.findUsers` — and each is absent, or a function: a value in its place (`findUsers: true`, a property copied from a config) is a wiring mistake, not an absent capability.
+**Why:** `store` is `{ users, sessions, tokens }`, and each slot must answer every method of the port. Three methods are optional — `sessions.deleteExpiredSessions`, `tokens.deleteExpiredTokens` and `users.findUsers` — and each is absent, or a function: a value in its place (`findUsers: true`, a property copied from a config) is a wiring mistake, not an absent capability.
 An adapter written for an earlier `@nxgt/janus` reports the method a later
 release added to the port: `store.tokens has no method countAttempt` for one
 written against 0.3 (the method came in 0.4), and
@@ -366,8 +366,8 @@ janus({ user: z.object({ username: z.string() }), password: { login: 'username'
 Also `janus: "<name>" cannot name a user type — janus() answers a method of that name` and `janus: users declares no user type`.
 
 **When:** `janus({ users: {...} })`.
-**Why:** each type becomes a property of what `janus()` answers — `auth.staff` — so it must be a name, and not one of the shared methods (`authenticate`, `signOut`, `signOutEverywhere`, `findUser`, `getUser`, `cookie`, `collectExpired`, `types`).
-**Fix:** `users: { staffMember: {...} }`, not `'staff-member'` or `cookie`.
+**Why:** each type becomes a property of what `janus()` answers — `auth.staff` — so it must be a name, and not one of the shared methods (`authenticate`, `signOut`, `signOutEverywhere`, `findUser`, `getUser`, `cookie`, `collectExpired`, `types`, `changeEmail`).
+**Fix:** `users: { staffMember: {...} }`, not `'staff-member'`, `cookie` or `changeEmail`.
 
 ### `janus: session.lifespan: "<value>" is not a duration; write a number followed by ms, s, m, h or d — for example "15m" or "720h"`
 
@@ -949,7 +949,7 @@ janus({ ..., hasher: scryptHasher(), verifiers: [bcryptVerifier] }); // a Passwo
 `TokenError`: `<call>: no such token`, `<call>: the token was already used`, `<call>: the token has expired`.
 
 **When:** `verifyEmail.confirm`, `resetPassword.confirm`, `changeEmail.confirm`.
-**Why:** a token is spent by its first use, and an expired one is spent too. `TOKEN_UNKNOWN` also covers a token whose user was deleted, and a change link confirmed through another user type's `changeEmail` or passed to another flow. The defaults are 24 h for `verifyEmail`, 1 h for `resetPassword` and for `changeEmail`. A change link is also spent by a newer `changeEmail.send` for the same user (only the last one works), and by an `update` that changes the user's e-mail.
+**Why:** a token is spent by its first use, and an expired one is spent too. `TOKEN_UNKNOWN` also covers a token whose user was deleted, and a change link confirmed through another user type's `changeEmail` (which spends it, so the right type then answers `TOKEN_SPENT`) or passed to another flow. The defaults are 24 h for `verifyEmail`, 1 h for `resetPassword` and for `changeEmail`. A change link is also spent by a newer `changeEmail.send` for the same user (only the last one works), and by an `update` that changes the user's e-mail.
 A reset link answers `resetPassword.confirm: the token was already used` in
 two more cases: a newer `resetPassword.request` for the same user spent it —
 only the last link sent works, so a visitor who asked twice and clicked the
@@ -958,7 +958,9 @@ sent, by another link's `confirm`, `changePassword` or `setPassword`. When two
 requests race, even the last link can be spent: at most one survives,
 sometimes none.
 **Fix:** answer 400 and offer to send a new link — and tell the visitor to use
-the latest e-mail. To change the lifetimes:
+the latest e-mail. With several user types, confirm a change link from a page
+that does not know the type with the root's `auth.changeEmail.confirm(token)`,
+never through a guessed type. To change the lifetimes:
 
 ```ts
 janus({ ..., tokens: { verifyEmail: '72h', resetPassword: '2h' } });
@@ -1069,11 +1071,11 @@ const page = await access.list(user, 'view', 'record', {
 });
 ```
 
-### `UNSUPPORTED` — `collectExpired: store.sessions does not implement deleteExpiredSessions — its store expires sessions on its own, or implement the method`
+### `UNSUPPORTED` — `collectExpired: store.sessions does not implement deleteExpiredSessions, nor store.tokens deleteExpiredTokens — their stores expire records on their own, or implement the methods`
 
 **When:** `auth.collectExpired()`.
-**Why:** the sessions store does not implement the optional `deleteExpiredSessions` — usually because it expires sessions itself (a MongoDB TTL index, a Redis `EXPIRE`).
-**Fix:** do not schedule `collectExpired` for that store. Expiry does not depend on it: the core compares `expiresAt` on every `authenticate`.
+**Why:** neither the sessions store implements the optional `deleteExpiredSessions` nor the tokens store the optional `deleteExpiredTokens` — usually because they expire records themselves (a MongoDB TTL index, a Redis `EXPIRE`). With one of the two, `collectExpired` collects that one and does not throw.
+**Fix:** do not schedule `collectExpired` for those stores. Expiry does not depend on it: the core compares `expiresAt` on every `authenticate` and on every redemption. If your database has no TTL, implement the methods ([adapters](guide/adapters.md#tokenstoredeleteexpiredtokens-optional)).
 
 ### `<call>: the <type> type does not sign in with a password — add password: { login } to it`
 

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@nxgt/janus",
-	"version": "0.24.0",
+	"version": "0.26.0",
 	"description": "Embeddable, type-safe identities and permissions: bring your own database",
 	"license": "MIT",
 	"type": "module",