Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#453 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
35/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
typescript
Domínio
authentication, authorization, backend

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
TypeScript
Estrelas
402
Forks
32
Merge médio
13h 14min
PRs com merge (30d)
73

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de voidzero-dev/void

Todas as issues de voidzero-dev/void

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.