Hacktoberfest 2026：維護者為十月標記出來的 issue，仍然開放、適合新手。 瀏覽 Hacktoberfest issue

[Feature]: Allow manifest actions to send HTTP headers, so engines behind authentication can be managed

未關閉
  • 哪裡不對？
#26 1 則留言 2 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 5 天內回覆

還沒有人認領這個 Issue。

評估

難度
5/5
預估耗時
一週以上
新手友好度
45/100
Issue 類型
功能
描述清晰度
基本清楚
活躍度
活躍
技術堆疊
go
領域
api, backend, security

研究方向

從 ActionHTTP 的 Go 定義開始，追蹤 action 請求的執行路徑，然後檢查每個 engine 的設定、runtime.env 和請求錯誤是如何處理的。在實作 headers 之前，先定義 secret 的來源和遮罩行為；完成的標準是：經過驗證的本機伺服器 action 成功，同一請求不帶其 header 時回傳 401，且失敗記錄中不包含 header 值。

由索引模型根據 Issue 內容生成。

描述

Area

Engine or model management

User problem

ActionHTTP in the engine manifest schema carries only a method, a path and a body schema:

type ActionHTTP struct {
    Method     string          `json:"method"`
    Path       string          `json:"path"`
    BodySchema json.RawMessage `json:"body_schema,omitempty"`
}

There is no way to send a request header, so any engine whose API requires authentication cannot be driven by a manifest at all. This is not an edge case — an engine that binds a loopback port and expects a bearer token is a normal shape, and it is the shape you get whenever a local engine also supports remote access.

The concrete example I ran into is Unsloth Studio. Its /api/health is open, so PAIR's readiness and health probes work fine and the engine looks perfectly manageable. But /v1/models returns:

HTTP 401  {"error":{"message":"Not authenticated","type":"authentication_error"}}

so list_models, loaded_models and every model operation fail. The engine can be started and monitored but not used, which is arguably worse than not supporting it at all, because the failure appears only after it looks healthy.

The same applies to vLLM started with --api-key, to SGLang behind a token, and to any engine reached through an authenticating proxy.

Desired outcome

An optional headers map on ActionHTTP, so a manifest can declare what an action needs to send:

"list_models": {
  "http": {
    "method": "GET",
    "path": "/v1/models",
    "headers": { "Authorization": "Bearer {api_key}" }
  },
  "result": { "array": "data", "field": "id" }
}

That implies a way to supply the secret, which is the part worth designing rather than assuming. Some options, roughly in order of how much they widen the trust surface:

  • a new {api_key}-style placeholder resolved from the existing per-engine settings the user already edits in the app, alongside the persisted port override
  • resolution from the engine's environment, reusing runtime.env so the value lives where the engine's other configuration already lives
  • a literal string in the manifest, which is simplest but puts a credential in a file users copy around, so probably worth refusing outright
Alternatives considered

An adapter process that holds the credential and presents an unauthenticated loopback surface to PAIR. This works — it is what I did — but it means every authenticated engine needs a sidecar to be manageable, and the credential ends up in a second place rather than in PAIR's own settings.

Skipping affected engines entirely is the current behavior, and it fails late rather than clearly: health probes pass, so the engine presents as healthy while every model action returns 401.

Compatibility and security implications

Additive and backward compatible: headers absent means today's behavior exactly, and existing manifests are unaffected.

The security consideration is where the secret comes from, not the header mechanism. A literal in the manifest would be the easy path and the wrong one, since manifests are user-editable files that get shared and pasted into issues. Sourcing from per-engine settings or runtime.env keeps the credential in the same places PAIR already treats as configuration. Redaction in logs would want checking too, since action URLs and errors are logged and a header value should never follow them there.

Scoping the feature to actions only, rather than to the readiness and health probes, would also keep the blast radius small — probes generally hit unauthenticated endpoints anyway, as the Unsloth case shows.

Validation approach

A manifest declaring a header against a local server that requires it, asserting the action succeeds and that the same action without the header returns 401. Plus a redaction test asserting the header value does not appear in logs on the failure path.

Happy to test against real engines on DGX Spark hardware if that is useful — the Unsloth Studio case above is reproducible on any machine with Studio installed.

主要語言
Go
星號
1.6k
分支
266
平均合併
3 天 6 小時
30 天內合併 PR
22

環境準備

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

NVIDIA/Personal-AI-Router 的其他 Issue

查看 NVIDIA/Personal-AI-Router 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。