Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
#3,319 2 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
rust

调研方向

首先,跟踪贯穿 Supervisor、Gateway、sandbox response 和 trusted control-plane API 的动态令牌授予失败路径。检查已配置的 token-service contract 和现有的 telemetry 边界,然后使用 acceptance criteria 定义确定性映射、redaction、correlation 和 fail-closed behavior。为列出的 status cases 添加 unit 和 end-to-end 覆盖,并确保 trusted client 只接收文档化的稳定分类。

由索引模型根据 Issue 内容生成。

描述

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.

主要语言
Rust
星标
8.7k
派生
1.3k
平均合并
2 天 3 小时
30 天内合并 PR
314

环境准备

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

NVIDIA/OpenShell 的其他 Issue

查看 NVIDIA/OpenShell 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。