Proposal: visitor (member) authentication + per-visitor data

[dazzakiller]

Hi — I've built a visitor-facing auth system and a per-visitor data framework on top of Instatic (fork: dazzakiller/Instatic, rebased onto v0.0.13). Before opening a PR, I wanted to gauge whether this is in scope / of interest.

The gap it fills: Instatic's auth is admin-only, so member portals, gated content, and personalised visitor pages aren't possible today. This adds the visitor side while keeping it fully decoupled from admin auth.

Two layers:

1. Visitor auth — register/login/logout, Argon2id, separate session cookie + middleware (different name, different tables, different code — zero runtime coupling to admin auth, enforced by an architecture-gate test), rate limiting + lockout, CSRF, member groups, page-level access control, password reset, an admin Members management UI, and built-in login/register pages.
2. Per-visitor data — site-builder-defined custom profile fields; two new perVisitor loop sources (visitor.current for "Welcome {name}" / custom fields, visitor.owned-rows for "your tenders"-style listings); form submissions auto-stamp the owning visitor; and the fields surface in the editor's {} binding picker.

Design principles I followed: 95%+ of published pages stay static on disk (auth adds ~0.1ms to the hot path); all visitor logic lives in new files with a ~20-line core diff; IDOR-safe by construction (visitor identity derives only from the validated session cookie, never request input).

Full design docs (PRD, review cycle, architecture, data-framework spec) are in docs/proposals/visitor-auth/
(https://github.com/dazzakiller/Instatic/tree/upstream-rebase/docs/proposals/visitor-auth) on the upstream-rebase branch. tsc -b clean, full test suite at parity with upstream main, dedicated security-gate tests for the IDOR boundary. Rebased cleanly onto v0.0.13.

Scope: ~10,700 lines across ~93 files (47 new). It's large because the two layers are inseparable (data depends on auth).

Transparency: built with AI assistance; I reviewed, tested, and verified every change against the full suite myself. Happy to walk through any part on a call.

Is this something you'd consider in scope? If so, I'll open a PR and split it into review-friendly commits. If not, no worries — I'll keep it as a fork.

— Dazza

[DavidBabinec]

Hey @dazzakiller ,

yeah, we definitely plan to have visitor auth for real member portals and better use of our dynamic "holes", which actually are made for this - as currently anything from the database can be baked into static pages, but those "holes" will work for content that needs to be unique to each request - eg. to each member.

However, this is huge scope and we are now working on a few big things that may conflict with it. I would wait until we pass through:

1. Real time collab editing - this is a big one, PR already open feat(editor): add real-time collaborative editing #305 - it enables real time collaboration of multiple authors on same pages, which also helps with agent work.
2. Code IDE for plugins inside Instatic - PR coming soon, already testing it internally
3. SEO - PR is also open, actually since the beginning :) So I will attend this one soon.

I am not sure how much overlap is there, but I will be happy to work on this with you. If you already have the code done, check especially the collab PR if there are conflicts with it and resolve them first, then open the PR and will check it out.

Thanks!

[dazzakiller]

Hey — thanks so much for the steer, and for being open to this. Really appreciate it.

I did the homework on #305 as you suggested: it's based on the same commit as my branch (d97cac2), so no rebase skew. The
overlap turned out small — 17 shared files, of which only 6 actually conflicted, and all six resolved additively (no
behaviour lost on either side):

• Migrations: your 022_collab_documents / 023_collab_document_generation keep their numbers; I renumbered my visitor
  migrations 022–027 → 024–029 so everything coexists.
• Loop sources: kept both your new EntryFieldSource and my visitor.current / visitor.owned-rows.
• DataPage: kept both your publish/draft flow and my page-access handler.
• Plus a couple of import/comment reconciliations and an isBuiltInValueLocked rename you'd made.

I merged #305 into my branch, resolved the lot, and verified: tsc clean, full suite green, zero regressions on either side's
code. My branch (upstream-rebase on dazzakiller/Instatic) now carries collab and the visitor work together, so opening the
PR shouldn't surprise you with conflicts.

What's in it, briefly:

• Visitor auth: register/login/logout, Argon2id, a separate session cookie + middleware fully decoupled from admin auth
  (different name, tables, code - locked by an architecture-gate test), rate limiting + lockout, CSRF, member groups,
  page-level access control, password reset, an admin Members management surface, and built-in login/register pages.
• Per-visitor data: site-builder-defined custom profile fields, plus two perVisitor loop sources (visitor.current for
  "Welcome {name}" / custom fields, visitor.owned-rows for per-member listings) that drive your holes exactly as you describe.
  Form submissions auto-stamp the owning visitor; the fields surface in the editor's {} binding picker. IDOR-safe by
  construction (identity derives only from the validated session cookie).

Design rationale (PRD, review cycle, architecture, data-framework spec) is in docs/proposals/visitor-auth/ if useful for
scoping.

One decision I'd value your view on: I kept visitor management as a separate Members area rather than folding it into the
existing Users menu — purely for simplicity at this stage. On reflection I suspect it'd be cleaner to unify everything under
one Users menu (admins and members as different "kinds" within it). I held off because that touches your existing Users
surface, but happy to do that refactor if you'd prefer it before the PR or as a follow-up.

Next: I'll open the PR from upstream-rebase. I built this with AI assistance but reviewed, tested, and verified every change
myself against the full suite — happy to walk through any part of it on a call if that's easier than a big-diff review.

(No rush on the plugin IDE / SEO PRs from my side — I can rebase again onto whatever main looks like by the time you get to
it.)

Thanks again 🙏

[dazzakiller]

PR done: #311