Flow route queue auth, stage 3: a signing mode for Worlds on external push-based queues

Abierto
  • ¿Algo no está bien?
#5,427 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
15/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
typescript
Área
authentication, security

Línea de trabajo

This is design work, so start by reading the QueueAuthMode type and its TODO in packages/world/src/queue.ts, then authorizeQueueDelivery() in packages/core/src/runtime/queue-auth.ts, and how keys are registered in @workflow/utils. The issue asks for a signed-delivery mode with key rotation and conformance tests in @workflow/world-testing, but the design is still a sketch. Done means an agreed design, then a mode whose refusals return 401 with the refused marker, never write to a run, and pass the gated conformance tests.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Summary

Queue.queueAuthMode (@workflow/world) tells the runtime how to authenticate a delivery that reaches the flow route (POST /.well-known/workflow/v1/flow). After #5179 and #5315 the modes are:

  • 'deny': a pull-based World. The World's worker runs inside the app's process and delivers to the route's in-process entry; the route refuses every HTTP request with a final 403. The Postgres World declares it.
  • 'allow': the route accepts HTTP because the platform already restricts who can reach it. The Vercel World declares it: only Vercel Queues can trigger the route, and the handler receives a message ID and leases the message through Vercel Queues. (Named 'skip' in @workflow/world 5.2.0; 'skip' is still accepted as a deprecated spelling.)
  • 'loopback': the Local World's shared queue key, a temporary mode until the Local World no longer delivers back to the app over its own routes.

None of these fits a World backed by an external push-based queue, such as Amazon SQS or Cloudflare Queues, that delivers to the flow route over HTTP from outside the app's platform: 'allow' leaves the route open to anyone who can reach it, and 'deny' cannot receive the delivery at all.

Stage 3: a signing mode

Add a mode in which the World signs each delivery and the runtime verifies the signature before it reads the body or touches any run.

Sketch, to be refined when the work starts:

  • The World holds the signing key and attaches a signature header to each delivery, over the body, the message ID, the attempt and a timestamp, so a captured delivery cannot be replayed later or against another message.
  • The runtime verifies with a key the World provides through the existing key-source registration in @workflow/utils, refuses a bad or stale signature with a 401 that carries the existing refused marker (so a sender can rotate keys and retry), and never writes to a run on a refusal.
  • Key rotation: accept the current and the previous key for a bounded window.
  • WORKFLOW_QUEUE_AUTH=off keeps its meaning (an emergency override, refused while dynamic workflows are enabled).
  • Conformance coverage in @workflow/world-testing, gated on the declared mode like the existing skipUnlessKeyChecked and skipUnlessDenied helpers.

The extension point is QueueAuthMode in packages/world/src/queue.ts and authorizeQueueDelivery() in packages/core/src/runtime/queue-auth.ts; a TODO next to the type points here.

Out of scope

Changing how 'deny' or 'allow' Worlds are checked, and the Local World's 'loopback' mode.

Lenguaje dominante
TypeScript
Estrellas
2.5k
Forks
401
Merge medio
2 d 36 min
PR fusionados (30 d)
150

Preparar el entorno

  • Sin Dockerfile ni archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de vercel/workflow

Todos los issues de vercel/workflow

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.