@nxgt/janus 0.13.0 → 0.15.0

package/dist/permissions/index.js

@@ -4,15 +4,15 @@ import {
   UNSTORABLE,
   MAX_PAGE_SIZE2,
   pageLimit2
-} from "../chunks/index-jp2kka6d.js";
+} from "../chunks/index-kj3st57z.js";
 import {
   PermissionDepthError2,
   isSetOf2,
   formatEntity2
-} from "../chunks/index-j2gd8fry.js";
+} from "../chunks/index-hnwggyxs.js";
 import {
   createMemoryRelations2
-} from "../chunks/index-km7ffctx.js";
+} from "../chunks/index-6c9fbtv2.js";
 
 // src/permissions/resolve/resolved.ts
 function admits(holders, subject) {

package/docs/README.md

@@ -14,11 +14,12 @@ below are defined once, in [Words](guide/vocabulary.md#words).
 | [Users](guide/users.md) | You are wiring `janus()`, declaring one or several user types, or calling `create`, `update`, `list`, `delete` |
 | [Sessions](guide/sessions.md) | You need to know who a request belongs to, set or clear the cookie, renew, sign out, or test expiry |
 | [E-mail verification and password reset](guide/email-flows.md) | You are sending a verification or reset link, and handling what comes back |
+| [Signing in with an e-mailed link](guide/magic-link.md) | You are signing users in with a link sent by e-mail — a magic link: the page that confirms it from a `POST` so mail scanners spend nothing, the lifetime, the errors, and what ends a link |
 | [Signing in with an e-mailed code](guide/sign-in-code.md) | You are signing users in with a six-digit code sent by e-mail — with no password, or beside one: requesting it without telling who exists, keeping the challenge, the attempts and the errors |
 | [The second factor](guide/second-factor.md) | You are turning on TOTP codes: making and rotating the sealing keys, the QR code, `signIn`'s `status`, confirming a challenge, recovery codes for a lost phone, disabling |
 | [Step-up](guide/step-up.md) | A sensitive action — changing the e-mail, disabling the second factor, deleting the account — should ask a signed-in user to prove again who they are: `assertFresh`, `stepUp.request` and `confirm`, by e-mailed code or by their app |
-| [User events](guide/events.md) | You want to hear when a user is created, verifies their e-mail, resets their password, turns the second factor on or off, uses a recovery code or is deleted — to queue it, sync it, or send it as a webhook |
-| [Password hashing](guide/passwords.md) | You are choosing a hasher, raising its cost, moving to argon2id, or importing hashes from another system — or rate-limiting password guesses |
+| [User events](guide/events.md) | You want to hear when a user is created, verifies their e-mail, resets or changes their password, changes their e-mail, turns the second factor on or off, uses a recovery code or is deleted — to queue it, sync it, or send it as a webhook |
+| [Password hashing](guide/passwords.md) | You are choosing a hasher, raising its cost, moving to argon2id, or importing hashes from another system — or how `signIn` throttles password guessing per login, and what you still limit per client |
 
 ### Permissions — `@nxgt/janus/permissions`
 
@@ -32,6 +33,6 @@ below are defined once, in [Words](guide/vocabulary.md#words).
 | --- | --- |
 | [The shared vocabulary](guide/vocabulary.md) | You want the words the documentation uses, or subjects and the tuple notation, ids, cursors, durations or `fixedClock` |
 | [Errors](guide/errors.md) | You are turning what the package throws into a status code, and want every code and what it carries |
-| [Writing an adapter](guide/adapters.md) | You are implementing the identity stores or the relation store for your database, upgrading one for `countAttempt`, `spendUserTokens` and the second factor, or running the conformance suites |
+| [Writing an adapter](guide/adapters.md) | You are implementing the identity stores or the relation store for your database, upgrading one for `countAttempt`, `spendUserTokens`, the second factor and a new token kind, or running the conformance suites |
 | [Troubleshooting](troubleshooting.md) | You have an error message and want its cause and its fix |
 | [Roadmap](roadmap.md) | You want to know what is coming, what shipped, and what is deliberately not planned |

package/docs/guide/adapters.md

@@ -160,7 +160,7 @@ update. A read followed by a write lets two requests redeem one reset token.
 A token is its hash, never its secret, and what it is for:
 
 ```ts
-type TokenKind = 'verifyEmail' | 'resetPassword' | 'secondFactor' | 'signInCode' | 'stepUp';
+type TokenKind = 'verifyEmail' | 'resetPassword' | 'secondFactor' | 'signInCode' | 'magicLink' | 'stepUp';
 
 interface TokenRecord {
 	readonly tokenHash: string;
@@ -178,9 +178,13 @@ interface TokenRecord {
 A token redeemed for another kind is unknown: every method that takes a
 `kind` matches on it. A `stepUp` token is a signed-in user's confirmation of
 a sensitive action; kept apart from `signInCode`, a sign-in code never
-confirms an action, nor an action's code signs anyone in. A store that lists
-the kinds — a `CHECK`, an enum in a validator — lists `stepUp` too, which
-`tokens.everyKind` proves. A `secondFactor` token is the challenge `signIn`
+confirms an action, nor an action's code signs anyone in. A `magicLink`
+token is a sign-in link's, new in 0.15, kept apart from `signInCode` the same
+way: a sign-in code's challenge is handed to whoever asked for it, and a
+store that redeemed it as a link would sign them in with no code —
+`tokens.magicLinkKind` holds that it does not. A store that lists the
+kinds — a `CHECK`, an enum in a validator — lists `stepUp` and `magicLink`
+too, which `tokens.everyKind` proves. A `secondFactor` token is the challenge `signIn`
 answers — or the count of a user's attempts at `regenerateRecoveryCodes`,
 a token of the same kind whose secret nobody is given, never redeemed and
 only counted — and its `address` is `''`: a column or a validator that refuses an
@@ -282,8 +286,8 @@ driver's error in `StoreFailure` as in [the six rules](#the-six-rules):
 Spends every **unspent** token of one user and one `kind` at `at` — but the
 one whose hash is `except`, when given — and answers how many it spent. The
 core calls it right after issuing a sign-in code, with that code's hash as
-`except`, so only the last code sent works — and so after issuing a step-up
-or a reset link; and after writing a password, for the user's
+`except`, so only the last code sent works — and so after issuing a sign-in
+link, a step-up or a reset link; and after writing a password, for the user's
 `resetPassword` links and `secondFactor` challenges:
 
 | The stored token | Written | Counted |
@@ -403,7 +407,7 @@ compile error naming the missing method.
 
 | Suite | Cases | Harness opens |
 | --- | --- | --- |
-| `describeJanusStores({ name, harness, runner?, faults?, skip? })` | 54: users, sessions, tokens, and one outage per method whose honest answer can be "nothing" — fourteen of them | `{ stores, faults?, close? }` |
+| `describeJanusStores({ name, harness, runner?, faults?, skip? })` | 55: users, sessions, tokens, and one outage per method whose honest answer can be "nothing" — fourteen 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

package/docs/guide/email-flows.md

@@ -34,11 +34,13 @@ verified.emailVerified; // true
 `sendMail` above is yours to write, or
 [`@nxgt/janus-mail`](https://www.npmjs.com/package/@nxgt/janus-mail)
 writes it: it takes what `send` and `request` answer, as they answer it, and
-sends the verification, reset and sign-in code e-mails — with the notices
+sends the verification, reset, sign-in code and sign-in link e-mails — with the notices
 of a password, an e-mail or a second factor changed, and a welcome on
 `user.created` — in English and French, over any `@nxgt/mail` transport.
-Every link is required: `getStarted`, since janus-mail 0.4.0, is where the
-welcome's **Get started** button leads.
+Every link is required but two: `getStarted`, since janus-mail 0.4.0, is
+where the welcome's **Get started** button leads; `recoveryCodes` and
+`magicLink` — the page a [sign-in link](magic-link.md) opens, since
+janus-mail 0.7.0 — are optional.
 
 ```ts
 import { janusMail } from '@nxgt/janus-mail';
@@ -91,8 +93,9 @@ clinic.patient.verifyEmail.send; // exists: `email` names the field
 clinic.staff.verifyEmail;
 ```
 
-A type with an e-mail can also sign in with a code sent to it, with or
-without a password — see [sign-in codes](sign-in-code.md).
+A type with an e-mail can also sign in with a code or a link sent to it,
+with or without a password — see [sign-in codes](sign-in-code.md) and
+[sign-in links](magic-link.md).
 
 ## Options
 
@@ -180,8 +183,8 @@ The links are spent **after** the password is written, so a link issued
 during the write is spent too. If the store fails at that step, the call
 rejects with `STORE_FAILED` although the password is written — answer 503 as
 usual — and the older links may still be live until the next `request`,
-which spends them. Sign-in codes and step-ups are not spent: the password
-proves neither.
+which spends them. Sign-in codes, sign-in links and step-ups are not spent:
+the password proves none of them.
 
 `confirm` sets the password, marks the e-mail verified — the link proved it —
 and **signs the user out everywhere**: their sessions are revoked, and every
@@ -234,6 +237,7 @@ never the token, and no refusal's message contains it.
 
 - [Users](users.md) — `email`, `update`, and the other per-type methods
 - [Sign-in codes](sign-in-code.md) — the third flow that sends an e-mail: a code, not a link
+- [Sign-in links](magic-link.md) — the fourth: a link that signs in, confirmed from a `POST` so a mail scanner spends nothing
 - [Sessions](sessions.md) — `signOutEverywhere`, which `resetPassword.confirm` calls for you
 - [User events](events.md) — `user.emailVerified` and `user.passwordReset`, which the confirms send
 - [Errors](errors.md) — every code, and the status it deserves

package/docs/guide/errors.md

@@ -54,11 +54,11 @@ that wired the library, so no handler needs to tell it apart.
 | `VERSION_CONFLICT` | `StoreConflict` (`on: 'version'`) | 409 | `ifVersion` no longer matches; nothing was written. From `secondFactor.confirm` or `recover`, the same code used by two sign-ins at once: the other opened the session | `expectedVersion`, `actualVersion` |
 | `USER_INVALID` | `UserInvalidError` | 400 | The fields failed the schema | `issues`, field by field |
 | `PASSWORD_TOO_SHORT` | `CredentialError` | 400 | Below `password.minLength` | `minLength` — never the password |
-| `CREDENTIALS_INVALID` | `CredentialError` | 401 | Unknown login, no password, or the wrong one — **one code for the three** | `reason`, for your logs only |
+| `CREDENTIALS_INVALID` | `CredentialError` | 401 | Unknown login, no password, or the wrong one — **one code for the three** — and any password, the right one included, at a login past its attempts in the window — see [throttling](passwords.md#password-guessing-is-throttled) | `reason`, for your logs only; `retryAfter`, the seconds until the next window, when throttled |
 | `HASH_UNSUPPORTED` | `CredentialError` | 400 | A stored hash no wired hasher reads | `hashPrefix` — never the hash |
-| `USER_INACTIVE` | `UserInactiveError` | 403 | Deactivated; told only to someone who gave the right password, or the right code | `userId` |
+| `USER_INACTIVE` | `UserInactiveError` | 403 | Deactivated; told only to someone who gave the right password, the right code, or a live sign-in link | `userId` |
 | `STEP_UP_REQUIRED` | `StepUpRequiredError` | 403 | `assertFresh`: the session proved who it is `maxAge` ago or more. Not a denial of the action — ask for a [step-up](step-up.md), then send the request again | `userId` |
-| `TOKEN_UNKNOWN`, `TOKEN_SPENT`, `TOKEN_EXPIRED`, `TOKEN_STALE` | `TokenError` | 400 | See [e-mail flows](email-flows.md#what-a-token-refusal-means). For a second factor's challenge: sign in again; for a sign-in code's: request a new code — see [sign-in codes](sign-in-code.md#what-confirm-refuses) | `userId` on `TOKEN_STALE` |
+| `TOKEN_UNKNOWN`, `TOKEN_SPENT`, `TOKEN_EXPIRED`, `TOKEN_STALE` | `TokenError` | 400 | See [e-mail flows](email-flows.md#what-a-token-refusal-means). For a second factor's challenge: sign in again; for a sign-in code's: request a new code — see [sign-in codes](sign-in-code.md#what-confirm-refuses); for a sign-in link: ask for a new link — see [sign-in links](magic-link.md#what-confirm-refuses) | `userId` on `TOKEN_STALE` |
 | `CODE_INVALID` | `TokenError` | 401 | A one-time code that does not match: a second factor's, or one already accepted — see [the second factor](second-factor.md#confirming-the-code-at-sign-in) — a recovery code not the user's, or already used — see [recovery codes](second-factor.md#signing-in-with-one) — or a sign-in code sent by e-mail — see [sign-in codes](sign-in-code.md#attempts) | `attemptsLeft` from either `confirm` and from `recover`: what the challenge has left, `0` once it is spent; from `regenerateRecoveryCodes`, what the user's 15-minute window has left, `0` past the fifth — see [regenerating them](second-factor.md#regenerating-them). None from `activate`. `userId` |
 | `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` |
@@ -81,7 +81,11 @@ async function signIn(email: string, password: string): Promise<Response> {
 		return Response.json({ token });
 	} catch (error) {
 		if (error instanceof CredentialError && error.code === 'CREDENTIALS_INVALID') {
-			console.warn('sign-in refused', error.reason); // 'unknownLogin' | 'noPassword' | 'wrongPassword'
+			console.warn('sign-in refused', error.reason); // 'unknownLogin' | 'noPassword' | 'wrongPassword' | 'throttled'
+			if (error.retryAfter !== undefined) {
+				const headers = { 'retry-after': String(error.retryAfter) };
+				return Response.json({ error: 'invalid', retryAfter: error.retryAfter }, { status: 401, headers });
+			}
 			return Response.json({ error: 'invalid' }, { status: 401 });
 		}
 		if (error instanceof StoreFailure) return new Response(null, { status: 503 });
@@ -96,6 +100,10 @@ async function signIn(email: string, password: string): Promise<Response> {
   would read as "no".
 - **`VERSION_CONFLICT` is a retry**: read the user again, reapply, write with
   the new `version`.
+- **`CREDENTIALS_INVALID`'s `retryAfter`** belongs in the body and a
+  `Retry-After` header: the login is throttled, and the right password is
+  refused too until then. It says nothing of whether the login exists — an
+  unknown one is throttled alike.
 - **`CODE_INVALID`'s `attemptsLeft`** belongs in the body — the form can say
   how many attempts are left. `0` means the challenge is spent: send the visitor
   back to the password.

package/docs/guide/events.md

@@ -1,8 +1,8 @@
 # User events
 
 This page is for hearing what happens to a user once it is written: created,
-e-mail verified, password reset, second factor turned on or off, recovery
-codes regenerated or one used, deleted. Another service can then follow
+e-mail verified, password reset or changed, e-mail changed, second factor
+turned on or off, recovery codes regenerated or one used, deleted. Another service can then follow
 without polling. `janus` hands each event to one function you give it;
 **delivering it is yours** — or
 [`@nxgt/janus-webhooks`](https://www.npmjs.com/package/@nxgt/janus-webhooks)'s:
@@ -38,13 +38,15 @@ received[0];
 The words — **user event**, **listener** — are defined in
 [the vocabulary](vocabulary.md#identities).
 
-## The eight types
+## The ten types
 
 | `type` | Sent by | Not sent |
 | --- | --- | --- |
 | `user.created` | `create`, `signUp` — once the user is inserted, even if `signUp`'s session then fails to open | for a sign-up refused (`LOGIN_TAKEN`, `USER_INVALID`, `PASSWORD_TOO_SHORT`) |
-| `user.emailVerified` | `verifyEmail.confirm`; `resetPassword.confirm`, whose link proves the e-mail; `signInCode.confirm`, whose code does | for an e-mail already verified, or a refused confirm |
+| `user.emailVerified` | `verifyEmail.confirm`; `resetPassword.confirm` and `magicLink.confirm`, whose link proves the e-mail; `signInCode.confirm`, whose code does | for an e-mail already verified, or a refused confirm |
 | `user.passwordReset` | `resetPassword.confirm` | for `setPassword` or `changePassword` — they are not resets |
+| `user.passwordChanged` | `changePassword` and `setPassword` — a first password set on a user created without one included — once the password is written — even if spending the reset links and second-factor challenges it ends then fails | for a reset, which is `user.passwordReset` alone; for a `changePassword` refused (`CREDENTIALS_INVALID`) |
+| `user.emailChanged` | `update`, when it changed the e-mail — added, replaced or removed. It carries `formerEmail`, the address before | for an update that leaves the e-mail alone, or changes only its case (`Ada@…` for `ada@…`): compared normalised, the same test that makes the new address unverified; for a type with no e-mail; for an update refused |
 | `user.secondFactorEnabled` | `secondFactor.activate`, once the first code made the factor active | for `enroll`, which leaves the factor waiting and asked for nowhere; for a code refused |
 | `user.secondFactorDisabled` | `secondFactor.disable`, when it removed an **active** factor | for a user who had no factor, a factor still waiting for its first code — it was never asked for — or a second `disable` |
 | `user.recoveryCodesRegenerated` | `secondFactor.regenerateRecoveryCodes`: the codes the user held stopped working | for `activate`, whose first codes come with `user.secondFactorEnabled`; for a code refused |
@@ -52,9 +54,13 @@ The words — **user event**, **listener** — are defined in
 | `user.deleted` | `delete`, when it deleted the user | for a replay that finds nobody, or an id of another user type |
 
 A reset whose link verifies the e-mail sends both, `user.passwordReset`
-first. Switch on `type`: the eight are a closed set, and TypeScript refuses a
-ninth. A new type is a compile error in a `switch` that exhausts them — the two
-recovery-code types, added in 0.10, broke such a `switch` until it handled them.
+first. **A reset does not also send `user.passwordChanged`**: a listener that
+cares about every new password handles both types, as the `switch` below
+does — one event per write, rather than two a listener would have to tell
+apart. Switch on `type`: the ten are a closed set, and TypeScript refuses an
+eleventh. A new type is a compile error in a `switch` that exhausts them — the
+two recovery-code types, added in 0.10, and the two change types, added in
+0.14, each broke such a `switch` until it handled them.
 
 ```ts
 function onUserEvent(event: UserEvent): void {
@@ -64,7 +70,10 @@ function onUserEvent(event: UserEvent): void {
 		case 'user.emailVerified':
 			return unlockFeatures(event.userId);
 		case 'user.passwordReset':
-			return alertSecurityTeam(event.userId);
+		case 'user.passwordChanged':
+			return noticeTheUser(event); // @nxgt/janus-mail's passwordChanged — see below
+		case 'user.emailChanged':
+			return noticeTheFormerAddress(event); // to event.formerEmail — see below
 		case 'user.secondFactorEnabled':
 		case 'user.secondFactorDisabled':
 			return noticeTheUser(event); // @nxgt/janus-mail's twoFactorEnabled or twoFactorDisabled
@@ -114,14 +123,59 @@ With several user types, the count is the type's:
 `auth.patient.secondFactor.recoveryCodesLeft(event.userId)`, on
 `event.userType`.
 
+### Telling the user their password or e-mail changed
+
+A password changed by someone else, or an e-mail moved to their inbox, is how
+an account is taken over — so tell the user each time. For a password, read
+the user and write to their address. For an e-mail, write to the **former**
+address: the new one belongs to whoever changed it. The event carries it,
+since nothing else keeps it once the write landed:
+
+```ts
+// `mail` is janusMail({ … }), and the user schema holds a name and a locale.
+const auth = janus({
+	...config,
+	async events(event) {
+		if (event.type === 'user.passwordChanged') {
+			const user = await auth.get(event.userId);
+			await mail.passwordChanged({ name: user.name, locale: user.locale, email: user.email });
+		}
+		if (event.type === 'user.emailChanged' && event.formerEmail != null) {
+			const user = await auth.get(event.userId);
+			await mail.emailChanged({
+				name: user.name,
+				locale: user.locale,
+				formerEmail: event.formerEmail, // to the inbox the account just left
+				newEmail: user.email,
+			});
+		}
+	},
+});
+```
+
+`formerEmail` is `null` for a user who had no e-mail before the update:
+there is no former inbox to tell. The example assumes a required e-mail; with
+an optional one, an update that removes it sends the event too, and the user
+read back has no `newEmail` to name — check `user.email` before the notice. Pass the same notices on `user.passwordReset`
+too, if a reset should be told as well.
+
 ## What an event carries
 
-**The user named by id, and nothing else.** No login, no e-mail, no field of
-the schema, no password or hash, no session or one-time token. An event can
+**The user named by id, and nothing else** — with one exception, below. No
+login, no field of the schema, no password or hash, no session or one-time
+token. An event can
 land in a queue, a log or another company's endpoint; whoever receives it
 reads the rest from where it is kept — `auth.get(event.userId)` — if they
 may. A user deleted since is `NOT_FOUND` there, which is the answer.
 
+**The exception is `formerEmail`, on `user.emailChanged` only**: the address
+the user had before the update, as it was stored, or `null` when they had
+none. Once the write landed it is kept nowhere else, and a notice to the
+inbox the account just left needs it. It is absent from every other type.
+`@nxgt/janus-webhooks` does not carry it: it strips it before the queue, so
+it reaches no endpoint, no queue and no `onGivingUp` report — send the
+notice from the listener, in the process that wrote.
+
 `id` is minted for the event, a UUIDv7 that sorts by time. Deliver on it:
 a queue job id, a primary key, a webhook's `webhook-id` header. Two events
 never share one.
@@ -148,15 +202,18 @@ Where the listener runs within a flow, and what an outage does to it:
 | `create` | after the insert — its last step | — |
 | `signUp` | after the insert, **before** the session is opened | fails the call; the event is already sent |
 | `verifyEmail.confirm` | after the write — the flow's last step | — |
-| `signInCode.confirm` | after the write, **before** the session or the second-factor challenge is opened | fails the call; the event is already sent |
+| `update` | after the write — the flow's last step | — |
+| `changePassword`, `setPassword` | **after** the reset links and the second-factor challenges left open are spent | fails the call; the event is sent all the same, from a `finally` |
+| `signInCode.confirm`, `magicLink.confirm` | after the write, **before** the session or the second-factor challenge is opened | fails the call; the event is already sent |
 | `secondFactor.activate`, `secondFactor.regenerateRecoveryCodes`, `secondFactor.disable` | after the write — the flow's last step | — |
 | `secondFactor.recover` | after the recovery code is spent and the session opened — or failed to open | fails the call; the recovery code is spent and the event sent all the same, from a `finally` |
 | `resetPassword.confirm` | **after** the sessions opened with the old password are revoked, and the other reset links and the second-factor challenges left open are spent | fails the call; the events are sent all the same, from a `finally` |
 | `delete` | **after** the user's sessions and one-time tokens are removed, and the relation tuples naming them when `relations` is wired | fails the call; the event is sent all the same, from a `finally` |
 
 So a listener that takes its time never leaves an old session alive after a
-reset, and one that checks permissions on `user.deleted` finds the tuples
-gone. A retry could not send a lost event either way: `delete` then finds
+reset, one that hears of a password changed finds the older reset links
+already spent, and one that checks permissions on `user.deleted` finds the
+tuples gone. A retry could not send a lost event either way: `delete` then finds
 nobody, and the reset link is spent.
 
 `occurredAt` is the write's own time: the `createdAt` or `updatedAt` it
@@ -231,6 +288,8 @@ type UserEventType =
 	| 'user.created'
 	| 'user.emailVerified'
 	| 'user.passwordReset'
+	| 'user.passwordChanged'
+	| 'user.emailChanged'
 	| 'user.secondFactorEnabled'
 	| 'user.secondFactorDisabled'
 	| 'user.recoveryCodesRegenerated'
@@ -243,6 +302,7 @@ interface UserEvent {
 	readonly occurredAt: Date; // when the write landed: the createdAt or updatedAt written, or the time read just before a deletion
 	readonly userId: Id;
 	readonly userType: string;
+	readonly formerEmail?: string | null; // on user.emailChanged only: the address before, null for none
 }
 
 type UserEventListener = (event: UserEvent) => void | Promise<void>;
@@ -257,5 +317,6 @@ see [troubleshooting](../troubleshooting.md#janus-events-must-be-a-function-that
 
 - [E-mail verification and password reset](email-flows.md) — the flows that send `user.emailVerified` and `user.passwordReset`
 - [The second factor](second-factor.md) — `activate` and `disable`, which send `user.secondFactorEnabled` and `user.secondFactorDisabled`; [recovery codes](second-factor.md#recovery-codes), which send `user.recoveryCodesRegenerated` and `user.recoveryCodeUsed`
-- [Users](users.md) — `create`, `signUp`, `delete`
+- [Users](users.md) — `create`, `signUp`, `update`, `delete`
+- [Passwords](passwords.md) — `changePassword` and `setPassword`, which send `user.passwordChanged`
 - [Troubleshooting](../troubleshooting.md) — `JANUS_EVENT_FAILED`