Pre-flight checklist
Problem or use case
Beyond WebSocket sessions, server has no first-party session, authentication, or composable middleware story. Every non-trivial service needs request-scoped sessions, some auth primitive, and a middleware pipeline; without them, adopters must hand-roll these or pull dependencies — which both undermines the "batteries-included, dependency-free backend" claim and is a blocker to server Stable (#131).
Proposed solution
Add a small, secure-by-default middleware pipeline plus session and auth primitives: signed/encrypted cookie sessions, a pluggable session store interface (in-memory default, bring-your-own for Redis/etc. without bundling a client), CSRF protection that composes with the security module, and minimal auth helpers (credential verification hooks, route guards mirroring the router's guard ergonomics). Keep each primitive independently importable and tree-shakeable.
Possible API or UX shape
import { createApp, session, csrf, guard } from "@bquery/bquery/server";
const app = createApp();
app.use(session({ secret: env.SECRET, store: memoryStore() }));
app.use(csrf());
app.route("GET", "/me", guard(ctx => !!ctx.session.userId), ctx => {
return ctx.renderResponse(MeView, { userId: ctx.session.userId });
});Alternatives considered
Documenting recipes for third-party session/auth libraries — contradicts the dependency-free goal and leaves security-critical code to users. A full identity provider — over-scoped; the right scope is primitives (sessions, CSRF, guards) that compose, not a turnkey auth system.
Relevant area
server
Additional context
Should reuse the existing security module (sanitize/Trusted Types/CSP) so the backend inherits secure-by-default behavior. Pairs naturally with form actions (#140) and file-based route actions (#149), which need server-side session context.
Pre-flight checklist
Problem or use case
Beyond WebSocket sessions,
serverhas no first-party session, authentication, or composable middleware story. Every non-trivial service needs request-scoped sessions, some auth primitive, and a middleware pipeline; without them, adopters must hand-roll these or pull dependencies — which both undermines the "batteries-included, dependency-free backend" claim and is a blocker toserverStable (#131).Proposed solution
Add a small, secure-by-default middleware pipeline plus session and auth primitives: signed/encrypted cookie sessions, a pluggable session store interface (in-memory default, bring-your-own for Redis/etc. without bundling a client), CSRF protection that composes with the security module, and minimal auth helpers (credential verification hooks, route guards mirroring the router's guard ergonomics). Keep each primitive independently importable and tree-shakeable.
Possible API or UX shape
Alternatives considered
Documenting recipes for third-party session/auth libraries — contradicts the dependency-free goal and leaves security-critical code to users. A full identity provider — over-scoped; the right scope is primitives (sessions, CSRF, guards) that compose, not a turnkey auth system.
Relevant area
serverAdditional context
Should reuse the existing security module (sanitize/Trusted Types/CSP) so the backend inherits secure-by-default behavior. Pairs naturally with form actions (#140) and file-based route actions (#149), which need server-side session context.