Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#453 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript
領域
authentication, authorization, backend

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
TypeScript
スター
402
フォーク
32
平均マージ
12時間 28分
マージ済み PR（30日）
77

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

voidzero-dev/void のほかの issue

voidzero-dev/void の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。