@plitzi/sdk-server 0.33.2 → 0.34.0

package/dist/core/auth/csrf.js

@@ -0,0 +1,234 @@
+import { appendCookies, sessionCookieParams } from "./session.js";
+import { createHmac, randomBytes, timingSafeEqual } from "node:crypto";
+//#region src/core/auth/csrf.ts
+/**
+* Cross-site request forgery: a page on another site causing a request here that the visitor did not mean to make.
+*
+* There are **two** attacks under that name, and they need different answers — conflating them is how a server
+* ends up either refusing legitimate sign-ins or leaving login CSRF wide open.
+*
+* 1. **An action taken as somebody.** A cookie is attached by the browser to every request to its origin,
+*    including ones another site caused. Not hypothetical here: `sessionCookieParams` defaults `SameSite` to
+*    `None` off localhost, because a Plitzi space is embedded in an iframe on somebody else's domain — which is
+*    exactly what `Lax` exists to prevent. Answered by a token, demanded whenever a session cookie is present.
+* 2. **Login CSRF.** Another site signs the visitor into an account IT controls, so what they do next is recorded
+*    against it. There is no cookie yet to look for, so the first answer does not apply at all. Answered by
+*    `foreign` below: where the request came from, which is what separates it from a legitimate sign-in.
+*
+* A request carrying `Authorization: Bearer` is at risk from neither and is never asked for a token: a
+* cross-origin page cannot set that header without a preflight the server would have to allow. Requiring one
+* there would break every API client to protect nobody.
+*
+* The token is a signed double-submit cookie: an HMAC over a nonce **and the session it belongs to**, handed to
+* the page in a readable cookie and echoed back in a header. An attacker's page cannot read the cookie, so it
+* cannot produce the header; and unlike plain double-submit, somebody who can merely *write* a cookie — a
+* sub-domain they took over — still cannot forge one, because they do not have the secret.
+*/
+var VERSION = "v1";
+/** GET, HEAD and OPTIONS change nothing, and demanding a token for them would break every ordinary navigation. */
+var SAFE_METHODS = /* @__PURE__ */ new Set([
+	"GET",
+	"HEAD",
+	"OPTIONS"
+]);
+/** Where the echo is looked for, and the field a `<form>` may carry it in instead. */
+var HEADER_NAME = "x-csrf-token";
+var FIELD_NAME = "_csrf";
+/** Twelve hours: long enough for a working day, short enough to bound a leak. */
+var TOKEN_LIFETIME = 43200;
+var csrfFailureMessage = {
+	missing: "A CSRF token is required",
+	malformed: "CSRF token malformed",
+	expired: "CSRF token expired",
+	mismatch: "CSRF token does not match this session"
+};
+var equal = (a, b) => {
+	const left = Buffer.from(a);
+	const right = Buffer.from(b);
+	return left.length === right.length && timingSafeEqual(left, right);
+};
+var header = (carrier, name) => {
+	const value = carrier.headers[name];
+	return typeof value === "string" ? value : void 0;
+};
+var readCookieHeader = (carrier, name) => {
+	if (carrier.cookies?.[name] !== void 0) return carrier.cookies[name];
+	const raw = header(carrier, "cookie");
+	if (!raw) return;
+	for (const part of raw.split(";")) {
+		const index = part.indexOf("=");
+		if (index !== -1 && part.slice(0, index).trim() === name) return decodeURIComponent(part.slice(index + 1).trim());
+	}
+};
+/** The host out of an `Origin`, which is a serialized origin (`https://acme.test:8443`) and never a bare host. */
+var originHost = (origin) => {
+	try {
+		return new URL(origin).hostname;
+	} catch {
+		return;
+	}
+};
+var createCsrf = (config) => {
+	const { secret, cookie, allowedOrigins = [] } = config;
+	const permitted = (origin) => typeof allowedOrigins === "function" ? allowedOrigins(origin) : allowedOrigins.includes(origin);
+	/**
+	* Did this request come from a site this deployment does not recognise?
+	*
+	* This is what protects signing in, where there is no session to bind a token to and no cookie to look for. It
+	* rests on two headers a page CANNOT set — the browser attaches both, and script may not override either:
+	*
+	* - **`Sec-Fetch-Site`** is the browser's own account of where the request came from, and is believed first.
+	*   Anything but `cross-site` (`same-origin`, `same-site`, or `none` for a typed URL) is this deployment's own.
+	*   The browser works that out with the real public suffix list, which is why it is worth more than anything
+	*   derivable here.
+	* - **`Origin`** is the fallback, for a browser too old to send the above — Safari only did from 16.4. Matched
+	*   **exactly**, against this host or an origin the deployment named.
+	*
+	* That exactness is deliberate and was a bug once: this compared *registrable domains*, last-two-labels, the
+	* same helper that scopes the session cookie. It has no public suffix list, so on a deployment at `acme.co.uk`
+	* every other `.co.uk` in the world counted as the same site and could sign a visitor in. Guessing where a
+	* domain boundary falls is not something to do in a security decision — a sibling sub-domain that needs to be
+	* trusted is one line in `allowedOrigins`, which `createAuth` already fills from `identity.platformOrigins`.
+	*
+	* **Neither header means this is not a browser**, and a client that is not a browser cannot be made to forge
+	* anything: there is no victim's session sitting in it. That is what keeps every API client, mobile app and
+	* script signing in with nothing extra to send.
+	*/
+	const foreign = (carrier) => {
+		const site = header(carrier, "sec-fetch-site");
+		const origin = header(carrier, "origin");
+		const allowed = origin !== void 0 && permitted(origin);
+		if (site !== void 0) return site === "cross-site" && !allowed;
+		if (!origin) return false;
+		return originHost(origin) !== carrier.hostname && !allowed;
+	};
+	const nameFor = (hostname) => `${sessionCookieParams(hostname, cookie).name}_csrf`;
+	const sign = (nonce, expiry, binding) => createHmac("sha256", secret).update(`${nonce}.${expiry}.${binding}`).digest("base64url");
+	/**
+	* `binding` is what ties a token to one session. Hashed rather than used raw so the token never carries a
+	* credential, even indirectly: it goes in a cookie a page can read.
+	*/
+	const bind = (sessionToken) => sessionToken ? createHmac("sha256", secret).update(sessionToken).digest("base64url") : "";
+	/**
+	* A token for this session, or for none.
+	*
+	* The unbound form is what protects sign-in itself: a page asks for one before anybody is authenticated, which
+	* is what stops another site logging a visitor into an account it controls. It is upgraded to a bound one the
+	* moment a session exists, and a bound token is refused for a different session.
+	*/
+	const issue = (sessionToken) => {
+		const nonce = randomBytes(16).toString("base64url");
+		const expiry = Math.floor(Date.now() / 1e3) + TOKEN_LIFETIME;
+		return `${VERSION}.${nonce}.${expiry}.${sign(nonce, expiry, bind(sessionToken))}`;
+	};
+	/** One place the cookie's attributes are decided, so writing it and dropping it cannot disagree about them. */
+	const serialize = (hostname, value, maxAge) => {
+		const params = sessionCookieParams(hostname, cookie);
+		return [
+			`${nameFor(hostname)}=${value}`,
+			"Path=/",
+			`SameSite=${params.sameSite === "none" ? "None" : "Lax"}`,
+			`Max-Age=${maxAge}`,
+			...params.domain ? [`Domain=${params.domain}`] : [],
+			...params.secure ? ["Secure"] : []
+		].join("; ");
+	};
+	const check = (token, sessionToken) => {
+		if (!token) return {
+			ok: false,
+			reason: "missing"
+		};
+		const [version, nonce, expiry, signature] = token.split(".");
+		if (version !== VERSION || !nonce || !expiry || !signature) return {
+			ok: false,
+			reason: "malformed"
+		};
+		const expiresAt = Number(expiry);
+		if (!Number.isFinite(expiresAt)) return {
+			ok: false,
+			reason: "malformed"
+		};
+		if (expiresAt < Math.floor(Date.now() / 1e3)) return {
+			ok: false,
+			reason: "expired"
+		};
+		/**
+		* Verified against the session the request actually carries. A token minted for nobody does NOT satisfy a
+		* request that has a session — otherwise an attacker could mint one from their own browser, where they are
+		* signed out, and replay it against a victim who is not.
+		*/
+		if (!equal(signature, sign(nonce, expiresAt, bind(sessionToken)))) return {
+			ok: false,
+			reason: "mismatch"
+		};
+		return { ok: true };
+	};
+	return {
+		issue,
+		/** The name the cookie lands under, for a client that reads it by hand. */
+		cookieName: nameFor,
+		/** The header the echo is expected in, published by `GET /auth/csrf` so a client is never told it twice. */
+		headerName: HEADER_NAME,
+		/** Readable on purpose: `httpOnly` would make it impossible for a page to echo it back. It is not a credential. */
+		write: (req, res, token) => {
+			appendCookies(res, [serialize(req.hostname, encodeURIComponent(token), TOKEN_LIFETIME)]);
+		},
+		/**
+		* Drops the cookie, on the same attributes it was written with — anything else leaves the original in place and
+		* adds a second one the browser then has to choose between.
+		*
+		* Called when a session ends. Nothing depended on it going: the token is signed over the session it belongs to,
+		* so once that session is revoked it verifies against nothing, and a write is only ever asked for a token when a
+		* session cookie is present. But a logout that leaves a cookie behind is one somebody has to reason about to
+		* dismiss, and on a shared browser "signed out" should mean nothing of the session is still sitting there.
+		*/
+		clear: (req, res) => {
+			appendCookies(res, [serialize(req.hostname, "", 0)]);
+		},
+		read: (carrier) => readCookieHeader(carrier, nameFor(carrier.hostname)),
+		/**
+		* Does this request need a token at all?
+		*
+		* Two requests can never be forged into, whatever they are reaching, and neither is ever asked:
+		*
+		* - a **safe method**, which changes nothing;
+		* - one presenting **`Authorization: Bearer`** — a cross-origin page cannot set that header without a
+		*   preflight this server would have to allow, so requiring a token would break every API client to protect
+		*   nobody.
+		*
+		* After that it depends on what the flow does, which is what `subject` says — an action taken as somebody is
+		* protected by the session cookie's presence, a sign-in by where the request came from. See {@link CsrfSubject}.
+		*/
+		required: (carrier, subject = "write") => {
+			if (SAFE_METHODS.has((carrier.method ?? "GET").toUpperCase()) || header(carrier, "authorization")) return false;
+			if (subject === "delegated") return false;
+			if (subject === "signIn")
+ /**
+			* Not "is there a session cookie". A sign-in does not act on the session the request carries — it
+			* REPLACES it — so a browser still holding a stale one was being refused the very request that fixes
+			* that. What matters is whether another site caused this.
+			*/
+			return foreign(carrier);
+			return readCookieHeader(carrier, sessionCookieParams(carrier.hostname, cookie).name) !== void 0;
+		},
+		/**
+		* The whole check. The echoed token must verify against the session the request carries, and — when the
+		* cookie is also present — match it. The second half costs nothing and blocks a token that leaked somewhere
+		* the cookie did not.
+		*/
+		verify: (carrier, sessionToken) => {
+			const field = carrier.body?.[FIELD_NAME];
+			const echoed = header(carrier, HEADER_NAME) ?? (typeof field === "string" ? field : void 0);
+			const result = check(echoed, sessionToken);
+			if (!result.ok) return result;
+			const fromCookie = readCookieHeader(carrier, nameFor(carrier.hostname));
+			if (fromCookie !== void 0 && !equal(fromCookie, echoed)) return {
+				ok: false,
+				reason: "mismatch"
+			};
+			return { ok: true };
+		}
+	};
+};
+//#endregion
+export { createCsrf, csrfFailureMessage };

package/dist/core/auth/csrf.test.d.ts

@@ -0,0 +1 @@
+export {};

package/dist/core/auth/identity.d.ts

@@ -11,6 +11,12 @@ export interface Actor {
     token: string;
     /** Unix seconds the presented credential dies at, off the stored row rather than the claim. */
     expiresAt: number;
+    /**
+     * The administrator behind this session, when somebody is acting AS this account — see `admin.impersonate`. Off
+     * the credential's `act` claim, so it survives into anything that reads an actor: an audit line that says who
+     * really did it, a UI banner, a flow that declines to run while borrowed.
+     */
+    impersonatedBy?: number;
 }
 /** A space token, resolved. `userId` is set for `agent` grants and names the member who consented. */
 export interface Grant {

package/dist/core/auth/identity.js

@@ -1,4 +1,5 @@
 import { domainAllowed } from "./domains.js";
+import { OFF_BROWSER_SPACE_SCOPES } from "./tokens.js";
 //#region src/core/auth/identity.ts
 var createIdentity = ({ tokens, carriers, adapters, config = {}, presentedOrigin }) => {
 	const { platformHosts = [], platformOrigins = [], allowWithoutOrigin = false, log } = config;
@@ -18,9 +19,13 @@ var createIdentity = ({ tokens, carriers, adapters, config = {}, presentedOrigin
 			ok: false,
 			reason: "expired"
 		};
+		const actingId = Number(verified.payload.act?.sub);
 		return {
 			ok: true,
-			actor
+			actor: Number.isInteger(actingId) ? {
+				...actor,
+				impersonatedBy: actingId
+			} : actor
 		};
 	};
 	const resolveActor = async (carrier) => {
@@ -85,13 +90,37 @@ var createIdentity = ({ tokens, carriers, adapters, config = {}, presentedOrigin
 				reason: "origin-not-allowed"
 			};
 		}
-		if (!origin) return allowWithoutOrigin ? {
-			ok: true,
-			grant
-		} : {
-			ok: false,
-			reason: "origin-not-allowed"
-		};
+		/**
+		* No `Origin` means no browser made this request — and what that is worth depends entirely on whether the
+		* credential was a secret to begin with.
+		*
+		* A **public** one — `render`, which ships in the clear inside every published page — is held to the allowlist
+		* even so, and therefore refused here. The check only ever worked because a BROWSER is made to state where it is
+		* presenting from; a client that simply omits the header is not proving anything, it is declining to be asked. If
+		* that were enough, a render key lifted from someone's page would be enough to serve a byte-identical clone of
+		* their site from any server, and the domain binding above would not stop it: a self-hosted renderer addresses
+		* this platform's own host, which is allowed by construction.
+		*
+		* A **secret** one — `host` for a server that renders the space as its own, `agent` for a consented integration —
+		* has nothing to prove by an origin, because possessing it is the proof. That is what `space:host` is FOR: it is
+		* shown once, never embedded, and revocable on its own row, so self-hosting no longer has to be paid for by
+		* making the public key work off-browser.
+		*/
+		if (!origin) {
+			if (OFF_BROWSER_SPACE_SCOPES.includes(scope) || allowWithoutOrigin) return {
+				ok: true,
+				grant
+			};
+			log?.("Access Not Authorized - Origin", {
+				spaceId,
+				scope,
+				reason: "public token presented with no Origin"
+			});
+			return {
+				ok: false,
+				reason: "origin-not-allowed"
+			};
+		}
 		if (!originAllowed(origin, origins)) {
 			log?.("Access Not Authorized - Origin", {
 				spaceId,

package/dist/core/auth/lifecycle.test.d.ts

@@ -0,0 +1 @@
+export {};

package/dist/core/auth/oauth/index.d.ts

@@ -60,6 +60,14 @@ export declare const createSocialAuth: ({ config, adapters, providers: configure
     /** Adapters for providers the server does not ship, merged over the built-in ones and selected the same way. */
     customProviders?: Partial<Record<string, OAuthProviderFactory>>;
 }) => {
+    /**
+     * Vet a caller-supplied landing page against this deployment's policy, for the flows that are not this one.
+     *
+     * Exposed because social sign-in is no longer the only thing that takes a `?redirect=` and then navigates to
+     * it: the shared sign-in screen does too, and the check has to be the SAME check. Two implementations of "is
+     * this target ours" is how one of them ends up accepting `//evil.com`.
+     */
+    sanitizeRedirect: (target: unknown) => string;
     /** Registered providers, so a front-end renders exactly the buttons that will work. */
     list: () => {
         id: string;

package/dist/core/auth/oauth/index.js

@@ -3,19 +3,13 @@ import { buildAuthorizationUrl, exchangeCodeForToken, requestProfileJson } from
 import { createGitHubProvider } from "./providers/github.js";
 import { createGoogleProvider } from "./providers/google.js";
 import { codeChallenge, consumeFlow, startFlow } from "./state.js";
+import { createRedirectPolicy } from "../redirects.js";
 //#region src/core/auth/oauth/index.ts
 /** The adapters shipped with the server. A deployment adds its credentials and gets the provider; nothing else. */
 var BUILT_IN_PROVIDERS = {
 	google: createGoogleProvider,
 	github: createGitHubProvider
 };
-var originOf = (value) => {
-	try {
-		return new URL(value).origin;
-	} catch {
-		return null;
-	}
-};
 /**
 * Social sign-in, as two functions and a list.
 *
@@ -39,16 +33,20 @@ var createSocialAuth = ({ config, adapters, providers: configured, customProvide
 			redirectUri: credentials.redirectUri || `${config.callbackBaseUrl ?? ""}/auth/${id}/callback`
 		}));
 	}
-	const sanitizeRedirect = (target) => {
-		const fallback = config.defaultRedirect;
-		if (typeof target !== "string" || target === "") return fallback;
-		if (target.startsWith("/") && !target.startsWith("//") && !target.startsWith("/\\")) return target;
-		const origin = originOf(target);
-		if (!origin) return fallback;
-		return [fallback, ...config.allowedRedirects ?? []].map(originOf).filter((value) => value !== null).includes(origin) ? target : fallback;
-	};
+	const sanitizeRedirect = createRedirectPolicy({
+		defaultRedirect: config.defaultRedirect,
+		allowedRedirects: config.allowedRedirects
+	});
 	const withError = (target, reason) => `${target}${target.includes("?") ? "&" : "?"}error=${encodeURIComponent(reason)}`;
 	return {
+		/**
+		* Vet a caller-supplied landing page against this deployment's policy, for the flows that are not this one.
+		*
+		* Exposed because social sign-in is no longer the only thing that takes a `?redirect=` and then navigates to
+		* it: the shared sign-in screen does too, and the check has to be the SAME check. Two implementations of "is
+		* this target ours" is how one of them ends up accepting `//evil.com`.
+		*/
+		sanitizeRedirect,
 		/** Registered providers, so a front-end renders exactly the buttons that will work. */
 		list: () => [...registry.values()].map((provider) => ({
 			id: provider.id,

package/dist/core/auth/passwords.d.ts

@@ -0,0 +1,15 @@
+/**
+ * Password hashing that a deployment does not have to choose, and by default does not even have to know about:
+ * this is what `createAuthApi` uses when nobody says otherwise.
+ *
+ * `scrypt` from the standard library, so this costs no dependency and nothing has to be compiled. It is a memory-hard
+ * KDF and an entirely respectable answer; argon2 or bcrypt are better ones, and a deployment that wants either passes
+ * its own `verifyPassword`/`hashPassword` to `createAuth` — nothing here assumes an algorithm.
+ *
+ * The format is `scrypt$<salt>$<hash>`, tagged so a later change of algorithm can recognise what it is looking at
+ * instead of guessing from the shape.
+ */
+export declare const hashPassword: (plain: string) => Promise<string>;
+export declare const verifyPassword: (plain: string, stored: string) => Promise<boolean>;
+/** Opaque single-use strings, for validation and password-reset links. */
+export declare const generateToken: () => string;

package/dist/core/auth/passwords.js

@@ -0,0 +1,32 @@
+import { randomBytes, randomUUID, scrypt, timingSafeEqual } from "node:crypto";
+import { promisify } from "node:util";
+//#region src/core/auth/passwords.ts
+var scrypt$1 = promisify(scrypt);
+var KEY_LENGTH = 64;
+/**
+* Password hashing that a deployment does not have to choose, and by default does not even have to know about:
+* this is what `createAuthApi` uses when nobody says otherwise.
+*
+* `scrypt` from the standard library, so this costs no dependency and nothing has to be compiled. It is a memory-hard
+* KDF and an entirely respectable answer; argon2 or bcrypt are better ones, and a deployment that wants either passes
+* its own `verifyPassword`/`hashPassword` to `createAuth` — nothing here assumes an algorithm.
+*
+* The format is `scrypt$<salt>$<hash>`, tagged so a later change of algorithm can recognise what it is looking at
+* instead of guessing from the shape.
+*/
+var hashPassword = async (plain) => {
+	const salt = randomBytes(16).toString("hex");
+	return `scrypt$${salt}$${(await scrypt$1(plain, salt, KEY_LENGTH)).toString("hex")}`;
+};
+var verifyPassword = async (plain, stored) => {
+	const [algorithm, salt, digest] = stored.split("$");
+	if (algorithm !== "scrypt" || !salt || !digest) return false;
+	const expected = Buffer.from(digest, "hex");
+	if (expected.length !== KEY_LENGTH) return false;
+	const actual = await scrypt$1(plain, salt, KEY_LENGTH);
+	return timingSafeEqual(expected, actual);
+};
+/** Opaque single-use strings, for validation and password-reset links. */
+var generateToken = () => randomUUID().replace(/-/g, "");
+//#endregion
+export { generateToken, hashPassword, verifyPassword };

package/dist/core/auth/redirects.d.ts

@@ -0,0 +1,18 @@
+export interface RedirectPolicyConfig {
+    /** Where a destination that is missing, malformed or not ours goes instead. Its own origin is always allowed. */
+    defaultRedirect: string;
+    /** Absolute targets a caller may name, compared by origin. */
+    allowedRedirects?: string[];
+}
+/**
+ * Vet a caller-supplied landing page against a deployment's policy: the target itself when it is ours, the default when
+ * it is not.
+ *
+ * Every flow that takes a `?redirect=` somebody else wrote and later navigates to it — social sign-in, the shared
+ * sign-in screen's way out, a confirmation mail that has to bring somebody back — asks THIS, built once from the same
+ * configuration. Two implementations of "is this target ours" is how one of them ends up accepting `//evil.com`.
+ *
+ * A relative path stays on the host that navigates to it and is allowed; a protocol-relative (`//evil.com`) or
+ * backslash (`/\evil.com`) one reads as a path and navigates off-site, and is not.
+ */
+export declare const createRedirectPolicy: (config: RedirectPolicyConfig) => ((target: unknown) => string);

package/dist/core/auth/redirects.js

@@ -0,0 +1,31 @@
+//#region src/core/auth/redirects.ts
+var originOf = (value) => {
+	try {
+		return new URL(value).origin;
+	} catch {
+		return null;
+	}
+};
+/**
+* Vet a caller-supplied landing page against a deployment's policy: the target itself when it is ours, the default when
+* it is not.
+*
+* Every flow that takes a `?redirect=` somebody else wrote and later navigates to it — social sign-in, the shared
+* sign-in screen's way out, a confirmation mail that has to bring somebody back — asks THIS, built once from the same
+* configuration. Two implementations of "is this target ours" is how one of them ends up accepting `//evil.com`.
+*
+* A relative path stays on the host that navigates to it and is allowed; a protocol-relative (`//evil.com`) or
+* backslash (`/\evil.com`) one reads as a path and navigates off-site, and is not.
+*/
+var createRedirectPolicy = (config) => {
+	const fallback = config.defaultRedirect;
+	const allowed = [fallback, ...config.allowedRedirects ?? []].map(originOf).filter((value) => value !== null);
+	return (target) => {
+		if (typeof target !== "string" || target === "") return fallback;
+		if (target.startsWith("/") && !target.startsWith("//") && !target.startsWith("/\\")) return target;
+		const origin = originOf(target);
+		return origin && allowed.includes(origin) ? target : fallback;
+	};
+};
+//#endregion
+export { createRedirectPolicy };

package/dist/core/auth/redirects.test.d.ts

@@ -0,0 +1 @@
+export {};

package/dist/core/auth/routes.d.ts

@@ -1,6 +1,7 @@
 import { AuthApi, AuthOutcome } from './api';
 import { AuthPolicy, Requirement } from './authorize';
 import { CredentialCarrier } from './credentials';
+import { Csrf } from './csrf';
 import { Actor } from './identity';
 import { CookieSink, SessionCookies } from './session';
 /**
@@ -28,9 +29,10 @@ export interface AuthRoute {
 }
 /** The flows, ready to mount. Which of them actually answer is decided by the API itself — no adapter, no endpoint —
  *  so mounting all of them is correct even for a deployment that offers three. */
-export declare const authRoutes: ({ api, cookies }: {
+export declare const authRoutes: ({ api, cookies, csrf }: {
     api: AuthApi;
     cookies: SessionCookies;
+    csrf?: Csrf;
 }) => AuthRoute[];
 /**
  * The same flows as authorization rules, for the guard that runs in front of them.
@@ -47,4 +49,4 @@ export declare const authPolicyRules: (prefix?: string) => AuthPolicy["rules"];
  */
 export declare const applySessionOutcome: (req: {
     hostname: string;
-}, res: CookieSink, outcome: AuthOutcome, cookies: SessionCookies) => void;
+}, res: CookieSink, outcome: AuthOutcome, cookies: SessionCookies, csrf?: Csrf) => void;