Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#453 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
typescript
Domaine
authentication, authorization, backend

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
TypeScript
Étoiles
402
Forks
32
Merge moyen
12 h 28 min
PR mergées (30 j)
77

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de voidzero-dev/void

Toutes les issues de voidzero-dev/void

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.