Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#453 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
typescript
Lĩnh vực
authentication, authorization, backend

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
TypeScript
Star
402
Fork
32
Merge trung bình
13 giờ 14 phút
Pull request đã merge (30 ngày)
73

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của voidzero-dev/void

Tất cả issue của voidzero-dev/void

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.