Skip to content
How much to read

Knowledge base

projects / clarity / decisions

One Pages Function gates the whole Clarity 2 project, not Cloudflare Access

Clarity 2's design-review login is a custom middleware function reading encrypted host settings, chosen over Cloudflare Access, HTTP Basic auth, and a repository-held credentials file.

decision · current · updated 2026-09-19 · Clarity case study

Context

The design-review epic needed the whole project, including every branch preview address and the clinic's own subdomain, reachable only by the dentist and his attendant, with a reload that does not ask again and nothing of the two credentials committed to the repository.

Decision

A single Pages Function (functions/_middleware.js, its logic in a tested package) runs in front of every request. It checks five encrypted host settings; if any is missing it serves nothing at all. A sign-in posts to /_auth, is checked against both people's credentials in constant time, and on a match sets a signed, 30-day, HttpOnly cookie recording which of the two people signed in. The host's own fail-open/closed setting is also set to fail closed, so a missing setting or an exhausted free-tier allowance cannot become an unguarded way in.

Alternatives rejected

  • Cloudflare Access: needs the domain to be a Cloudflare zone, and the clinic's nameservers stay at the registrar.
  • HTTP Basic auth: the browser's own prompt cannot carry which of the two people signed in, and it is not a page that can grow later.
  • A .env file: the two credentials would enter the repository.
  • A _redirects file: unnecessary, since Cloudflare Pages already treats a project with no 404.html as a single-page app.
  • Wrangler configuration: the Git-connected project needs none.

Why

The custom address and every preview address are the same Pages project, so gating at the Function layer is the only way to close every door with one mechanism, and the cookie's role field is needed by the next work order to open the right shell for each person.

Consequences

The sign-in page carries no design, since a separate work order owns the look. The two credentials exist only as encrypted settings created directly on the host by the PM; the builder never sees them. Clause (i) of Cloudflare's terms, on protected health information, does not bite during the made-up-data design review but is flagged as a decision still owed before cutover.

Status

Built and verified, live at the clinic's own subdomain over HTTPS, by a fresh checker context that did not see the build.

This page was written by a model from my own repositories and checked by a second one against the same sources. I did not write it, and no version of it was approved by me before it went up. How that works, and where it can still be wrong.