Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

[Server] Bind Streamable HTTP sessions to the authenticated principal

Đang mở
  • Có gì không ổn?
#529 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
32/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
php
Lĩnh vực
api, authentication, backend, security

Hướng nghiên cứu

Start from Protocol::resolveSession() and StreamableHttpTransport session load/destroy (Mcp-Session-Id, sessionManager exists/createWithId/destroySession) plus AuthorizationMiddleware. The issue wants a stable identity fingerprint stored on initialize and compared on later POST/DELETE (404 on mismatch). Read the linked MCP session-hijacking guidance, then decide with maintainers the open questions (always vs opt-in, Protocol vs store keying, opaque tokens) before coding; done is sessions bound to the principal without accepting another valid token on the same ID.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Server

Currently a stateful StreamableHttpTransport session is resolved only by its Mcp-Session-Id header - Protocol::resolveSession() checks sessionManager->exists() and loads it with createWithId(), and DELETE goes straight to destroySession(). With AuthorizationMiddleware in front, every request is still authenticated with the caller's own token and scopes are not inherited, but the session doesn't know which principal created it. So a request with a different valid token and the same session ID is accepted into that session, DELETE included.

Session IDs are random UUIDs, so this isn't easy to hit - still, the spec's security best practices say servers SHOULD bind session IDs to user-specific information: https://modelcontextprotocol.io/specification/2025-11-25/basic/security_best_practices#session-hijacking (the draft has the same as "state handle hijacking").

Thanks @GEONWOOHAN for bringing this up.

Rough direction:

  • AuthorizationResult exposes a stable identity - issuer + subject rather than sub alone, maybe the client id as well
  • the transport passes that into session resolution
  • on initialize we store a fingerprint of it in the session, later POST/DELETE compare and answer 404 on mismatch

Open questions:
a) bind always when an identity is present, or opt-in via the builder?
b) does it belong into Protocol or rather the session manager / store, so a custom store can key on <principal>:<session id>?
c) what about validators that don't produce a subject (opaque tokens, API keys)?

Keeping the core unaware of OAuth would be nice, so probably a plain identity string rather than the auth result itself.

WDYT?

Ngôn ngữ chính
PHP
Star
1.6k
Fork
177
Merge trung bình
5 ngày 8 giờ
Pull request đã merge (30 ngày)
18

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của modelcontextprotocol/php-sdk

Tất cả issue của modelcontextprotocol/php-sdk

Issue tương tự

Thêm issue về PHP

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.