cloudflare-toolkit

Appearance

@adrianhall/cloudflare-toolkit

@adrianhall/cloudflare-toolkit / lib/vite / CloudflareAccessPluginOptions

Interface: CloudflareAccessPluginOptions ​

Defined in: src/lib/vite/plugin.ts:69

Configuration for cloudflareAccessPlugin.

Properties ​

devSecret? ​

optional devSecret?: string

Defined in: src/lib/vite/plugin.ts:113

HMAC secret used to sign the dev JWT.

Must match the devSecret passed to cloudflareAccess in the Worker (if overridden there). Defaults to the same well-known development key.

loginPath? ​

optional loginPath?: string

Defined in: src/lib/vite/plugin.ts:122

Pathname for the login form (default "/cdn-cgi/access/login").

policies? ​

optional policies?: PathPolicy[]

Defined in: src/lib/vite/plugin.ts:105

Path policies evaluated in order (first match wins).

Pass the same array you give to cloudflareAccess in the Worker (../hono/cloudflare-access.ts) so dev and prod agree on which paths are protected.

  • authenticate: false — public (no gating, no header injection).
  • authenticate: true — protected (see below).
  • No matching policy — protected, exactly as if a matching authenticate: true policy with the default redirect: true had been found. This plugin has no defaultAction equivalent to cloudflareAccess's, so list an authenticate: false policy for anything that must stay reachable unauthenticated.

A protected path is always answered by this plugin and is never forwarded to the Worker unauthenticated (#203), because deployed Cloudflare Access protects a path regardless of request type. An unauthenticated HTML navigation is redirected to the dev login form (unless the matched policy sets redirect: false); every other unauthenticated request — an RSC/fetch-shaped request, a POST, an OPTIONS preflight, or any redirect: false route — receives a 401 RFC 9457 application/problem+json response, the same shape cloudflareAccess returns in the Worker, since there is no browser to hand a login form to.

Because of this, a broad authenticate: true pattern also gates subresource requests that Vite would otherwise serve (/favicon.ico, files copied from public/, /.well-known/…) — a 401 on those fails silently in the browser and renders a partial page. Vite's own internals (/@vite, /@fs, /@id, /@react-refresh, /node_modules/, /__vite, /src/) are always exempt; add an authenticate: false policy for any other asset path your app serves from a protected prefix.

A policy's own audience (see PathPolicy.audience, ../auth-internal/types.js) is enforced here too: an existing session cookie whose dev token doesn't carry the matched path's audience is treated as unauthenticated for that request, mirroring cloudflareAccess in the Worker (#181). The dev login form issues one session token whose aud claim covers every audience referenced across policies, so a single local sign-in can still reach every role-specific page rather than requiring a separate login per audience.

tokenLifetime? ​

optional tokenLifetime?: number

Defined in: src/lib/vite/plugin.ts:125

Dev JWT lifetime in seconds (default 86400 / 24 h).

users? ​

optional users?: DevLoginUser[]

Defined in: src/lib/vite/plugin.ts:119

Selectable identities rendered on the dev login form. When omitted the form shows a single free-text email input.