Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[Server] Bind Streamable HTTP sessions to the authenticated principal

Abierto
  • ¿Algo no está bien?
#529 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
32/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
php
Área
api, authentication, backend, security

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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?

Lenguaje dominante
PHP
Estrellas
1.6k
Forks
177
Merge medio
5 d 8 h
PR fusionados (30 d)
18

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de modelcontextprotocol/php-sdk

Todos los issues de modelcontextprotocol/php-sdk

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.