Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Project Zero Trust: per-project visitors for external reviewers (without an Access seat each)

Aperta
  • Qualcosa non va?
#453 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
authentication, authorization, backend

Direzione di ricerca

Start with the dispatch access check at platform/packages/dispatch/src/access.ts and read the Zero Trust configuration and domains guide mentioned in the issue. Compare the three proposed visitor access directions, including how each scopes access to a project and handles session cookies. Done means the project has an agreed direction for per-project reviewer access; implementation scope is not yet defined.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Use case

We are a small agency. Non-engineers on our team build mock apps with AI coding agents and share them with client companies for review. We run dozens of mocks at a time, each for a different client, and every mock must be private by default.

Project Zero Trust gets us most of the way: protection is on by default, it covers every path, and dispatch fails closed. Two things keep us from adopting it for this use case.

Problem 1: one policy for every project

void platform zero-trust configure --policies applies one set of policies to the shared wildcard application. A reviewer from client A who can sign in to one protected project can sign in to every protected project, including client B's. Per-project overrides are only protect / public.

Adding our own exact-host Access application per project does not work. Dispatch verifies Cf-Access-Jwt-Assertion against the audience Void recorded (platform/packages/dispatch/src/access.ts), so a token issued for our own application gets a 403. That check is correct; it just leaves no supported way to scope visitors per project.

Problem 2: every external reviewer takes a Zero Trust seat

Each person who signs in through Access consumes a seat. In our account today, 39 of 50 free seats are taken, and 36 of those 39 belong to external client reviewers. 38 of the 39 signed in within the last month, so seat expiration (already at the 1-month minimum) frees almost nothing. Reviewers are occasional, numerous, and outside our organization, which is the case where per-seat pricing fits worst.

Possible directions

Listed only to start the discussion. We would like to know which direction, if any, fits Void.

  1. Per-project Access policies. Reuse the existing exact-host application that Void already creates for protected projects with custom domains, and let project administrators attach an email allowlist to it. This solves problem 1 but not problem 2.
  2. Void-managed visitor access. Dispatch checks a Void-issued, host-scoped visitor session instead of an Access assertion. Visitors sign in with an email one-time code sent through the platform's email gateway, and project administrators manage an allowlist (void project visitors add <email>). This solves both problems and needs no Zero Trust seats.
  3. A pluggable visitor verifier. Keep the dispatch check where it is, but let a custom runtime swap projectAccessVerifier through a documented seam, so operators can bring their own gate without maintaining a fork of dispatch.

For option 2, the session cookie must stay host-only. As the domains guide notes, apps on one application domain can set cookies the others receive, so a session on the parent domain would let one project read another client's session.

Happy to help test or contribute if one of these directions is acceptable.

Lingua principale
TypeScript
Stelle
402
Fork
32
Merge medio
12h 28m
PR unite (30g)
77

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di voidzero-dev/void

Tutte le issue di voidzero-dev/void

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.