Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

feat(proxy): preserve typed dynamic token-grant failures across the sandbox boundary

Abierto
  • ¿Algo no está bien?
#3,319 2 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
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
rust
Área
api, authentication, observability, security

Línea de trabajo

Comienza siguiendo la ruta de fallo de la concesión dinámica de tokens a través de Supervisor, Gateway, sandbox response y trusted control-plane API. Revisa el token-service contract configurado y los límites de telemetría existentes y, a continuación, utiliza los acceptance criteria para definir mapeos deterministas, redaction, correlation y fail-closed behavior. Añade cobertura unitaria y end-to-end para los status cases enumerados y asegúrate de que el trusted client reciba únicamente la clasificación estable documentada.

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

Descripción

area:providers area:supervisor state:validated topic:l7

Summary

Preserve safe, structured dynamic token-grant failure classifications across the Supervisor proxy boundary instead of collapsing every token acquisition failure into an opaque 502 Bad Gateway.

Problem

During an integration POC with an external token service, an outbound request matched its provider policy and initiated the configured dynamic token grant. The upstream token service returned 401 Unauthorized, but the sandbox caller received only a generic 502 Bad Gateway.

This fail-closed behavior correctly prevented the request from reaching the destination without a credential. However, the trusted application/control plane could not distinguish an actionable authorization condition, such as a missing or revoked provider authorization, from invalid workload identity, token-service outage, timeout, or malformed configuration.

The sandbox must not receive raw token-service errors, token-service internals, authorization URLs, credentials, or identity details. A trusted caller still needs a stable classification so it can initiate the appropriate recovery flow.

Requested behavior

  • Define a stable, sanitized error taxonomy for dynamic token-grant failures.
  • Preserve a recognized token-service condition such as provider_authorization_required through the Supervisor/Gateway status or trusted control-plane API.
  • Continue returning a non-sensitive, fail-closed error to the sandbox request.
  • Distinguish at least:
    • provider/user authorization required;
    • workload identity or assertion rejected;
    • provider/token-grant configuration error;
    • upstream timeout or unavailable service;
    • unclassified upstream failure.
  • Include a correlation ID that lets operators join the sandbox denial, Supervisor event, Gateway event, and token-service event without exposing tokens.
  • Do not infer provider_authorization_required from every upstream 401; only propagate an explicitly recognized, authenticated contract from the configured token service.

Acceptance criteria

  • A token service's authenticated, typed provider_authorization_required response is available to an authorized trusted control-plane client using a documented stable code.
  • The sandbox response and sandbox-visible logs contain no token-service response body, authorization URL, bearer token, JWT-SVID, or provider secret.
  • An invalid/expired JWT-SVID remains distinguishable from provider authorization required in trusted telemetry.
  • 401, 403, 409, 429, timeout, and 5xx token-service cases have deterministic documented mappings.
  • The enterprise request is never forwarded when token resolution fails.
  • Unit and end-to-end tests cover the mappings, redaction, correlation, and fail-closed behavior.

Observed POC behavior

The proxy returned 502 while trusted OpenShell logs showed that the intermediate provider token exchange failed with upstream 401 Unauthorized. This RFE requests an error contract; it does not request exposing the raw upstream response to the agent.

Lenguaje dominante
Rust
Estrellas
8.7k
Forks
1.3k
Merge medio
1 d 21 h
PR fusionados (30 d)
312

Preparar el entorno

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 NVIDIA/OpenShell

Todos los issues de NVIDIA/OpenShell

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.