Auth / foldkit-auth/server

AuthServer

namespace · packages/auth/src/server.ts:152

const AuthServer = { resolver, answered }

In the guides

Members

AuthServer.resolver

function · packages/auth/src/server.ts:104

resolver<I, S extends VerifiedSession, User, R = never>(
  config: ResolverConfig<I, S, User, R>,
): Resolver<User, I | R>

Who a request is, from its Yielded session cookie, for a host's resolvePrincipal. No cookie is a visitor (Option.none()). A cookie is used only from a request that shows it came from the application, as Yielded's own mutations must: an Origin it trusts and, for requests: 'scripted', its CSRF header. From any other it is refused, as is a cookie that no longer verifies, two of them, or an x-foldkit-subject naming someone else. A session store that fails is a defect, never a visitor. Throws when http names an origin that is not one.

ts
serveFetch({
  server,
  resolvePrincipal: AuthServer.resolver({
    auth: AppAuth,
    http, // the options given Http.make(AppAuth, http)
    principal: session => Users.find(session.subjectId),
  }),
  layer: env => AuthLive(env),
})

AuthServer.answered

function · packages/auth/src/server.ts:193

answered<User>(config: {
  readonly key: (user: User) => string
}): (principal: Option.Option<User>) => Readonly<Record<string, string>>

The header saying whom an answer was for, for serveFetch's headers: what believing's fetch repeats on the client's next request, so the resolver refuses it once the cookie means someone else. Takes the resolver's own config, whose key it requires, so the two name the principal alike.

ts
const auth = { auth: AppAuth, http, principal, key: Policy.key }
serveFetch({
  server,
  resolvePrincipal: AuthServer.resolver(auth),
  headers: AuthServer.answered(auth),
  layer: env => AuthLive(env),
})