Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#26 コメント 1 件 リアクション 2 件 担当者 0 名 GitHub で見る

メンテナーはふだん 5 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
45/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
go
領域
api, backend, security

調査の方向性

ActionHTTP の Go 定義から始め、action リクエストの実行パスを追跡し、その後、エンジンごとの設定、runtime.env、リクエストエラーがどのように処理されるかを確認します。ヘッダーを実装する前に、secret のソースと秘匿化の動作を定義します。完了の条件は、認証済みのローカルサーバー action が成功し、同じリクエストがヘッダーなしでは 401 を返し、失敗ログにヘッダー値が含まれないことです。

索引モデルが 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時間
マージ済み PR（30日）
22

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

NVIDIA/Personal-AI-Router のほかの issue

NVIDIA/Personal-AI-Router の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。