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

auth: resource metadata lookup accepts URLs from non-Bearer challenges

オープン 初心者向け
#1,379 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

@jay23606 がすでに取り組んでいます。

2026年10月12日 から。

  • #1396 @jay23606 による — オープン

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
82/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
go

調査の方向性

resourceMetadataURLFromChallengesを読み、scopesFromChallengesおよびerrorFromChallengesのフィルタリングと比較してください。issueに示されているパッケージレベルの回帰テストを実行し、その後、helperの既存テストに追加してください。Bearer以外のchallengeが無視され、Bearer challengeのリソースメタデータURLが返されれば完了です。

索引モデルが issue の本文から書いたものです。

説明

Describe the bug

auth.resourceMetadataURLFromChallenges returns the first resource_metadata auth-param without checking the challenge scheme. The adjacent scopesFromChallenges and errorFromChallenges helpers correctly restrict their lookups to Bearer challenges.

As a result, a mixed response such as:

WWW-Authenticate: Basic resource_metadata="https://basic.example/metadata", Bearer resource_metadata="https://mcp.example/metadata"

causes AuthorizationCodeHandler to discover OAuth metadata from https://basic.example/metadata, even though resource_metadata is an MCP Bearer-challenge parameter and the Bearer challenge points elsewhere.

To Reproduce

On main at 944ac19, this package-level test fails:

func TestResourceMetadataURLFromChallengesIgnoresNonBearer(t *testing.T) {
	challenges := []oauthex.Challenge{
		{Scheme: "basic", Params: map[string]string{"resource_metadata": "https://basic.example/metadata"}},
		{Scheme: "bearer", Params: map[string]string{"resource_metadata": "https://mcp.example/metadata"}},
	}
	if got, want := resourceMetadataURLFromChallenges(challenges), "https://mcp.example/metadata"; got != want {
		t.Fatalf("resourceMetadataURLFromChallenges() = %q, want %q", got, want)
	}
}

The current result is https://basic.example/metadata.

Expected behavior

Only a Bearer challenge should supply resource_metadata, matching the filtering already used for scope and error. The current MCP authorization examples attach resource_metadata to the Bearer challenge, and RFC 6750 defines Bearer challenge parameters in WWW-Authenticate.

Additional context

The fix should be a small, unexported behavior correction: require c.Scheme == "bearer" in resourceMetadataURLFromChallenges and add the mixed-challenge regression test above. I would be happy to send that PR if this approach looks right.

Environment: go-sdk main at 944ac19, Go 1.25.0, macOS/arm64.


AI assistance disclosure: I used Codex to inspect the auth flow and draft the reproducer; I reviewed the source, specification references, and issue text.

主要言語
Go
スター
5.2k
フォーク
583
平均マージ
1日 8時間
マージ済み PR(30日)
50

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

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

modelcontextprotocol/go-sdk のほかの issue

modelcontextprotocol/go-sdk の issue をすべて見る

似ている issue

Go の issue をもっと見る

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

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