Symfony 8.2 ist für Ende November 2026 geplant. Der Support soll im Juli 2027 enden. Voraussetzung ist PHP 8.4.0 oder neuer. Der Entwicklungszweig kann sich bis zur Veröffentlichung noch ändern, deshalb sollten die Beispiele nicht in produktiven Systemen laufen.

<?php
namespace App\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Attribute\Route;
use Symfony\Component\Security\Http\Attribute\IsGranted;

class AccountController extends AbstractController
{
    #[Route('/account/delete', name: 'app_delete_account')]
    #[IsGranted('IS_AUTHENTICATED_VERY_RECENTLY')]
    public function deleteAccount(): Response
    {
    }
}

Jede Symfony-Komponente erhält ihr eigenes Bundle mit Konfiguration und Services. Symfony 8.2 bringt 29 Bundles mit, darunter CacheBundle, HttpClientBundle, MailerBundle und MessengerBundle. Bei der Installation registriert Symfony die Bundles automatisch, config/bundles.php muss nicht angepasst werden. Bestehende framework.*-Einstellungen bleiben ohne Deprecation gültig. Die framework-Wurzelebene kann schrittweise entfallen. Aus framework.assets wird asset, aus framework.translator wird translation und aus framework.workflows wird workflow. Lock und semaphore akzeptieren direkt eine DSN. Die Konfigurationsprüfung verwendet künftig debug:config mailer. Der Befehl debug:config framework mailer funktioniert nicht mehr. Formulare aktivieren die Validierung nicht mehr automatisch. Dafür genügt die Installation von symfony/validator. RedirectController liegt künftig in Routing, TemplateController in TwigBundle. Die zusätzlichen Bundles erzeugen ihre Objekte erst bei Bedarf und erhöhen deshalb nicht die Request-Kosten. FrameworkBundle bleibt das HTTP-Kernframework.

Für Bundle-Autoren kommen die ConfigBuilder-Methoden aliasOf() und appendFromCallback(). aliasOf() leitet einen Wurzelknoten an die Konfiguration einer anderen Extension weiter. Damit bleibt framework.workflows kompatibel. Die Workflow-Komponente besitzt workflow. appendFromCallback() fügt Knoten aus einem Callback hinzu und erhält die Fluent-Kette. Klassen, die aus FrameworkBundle in ihre Komponenten verschoben wurden, sind veraltet.

Die Security-Komponente erhält eine Sudo-ähnliche erneute Anmeldung. IS_AUTHENTICATED_RECENTLY akzeptiert standardmäßig eine Anmeldung aus den vergangenen zwei Stunden. IS_AUTHENTICATED_VERY_RECENTLY begrenzt den Zeitraum auf fünf Minuten. Die Prüfungen funktionieren in access_control, Twig und Controller-Attributen. Für Security-Ausdrücke kommen is_recently_authenticated() und is_very_recently_authenticated() hinzu. Ein Remember-me-Cookie reicht für keine der beiden Prüfungen. Beide Zeiträume lassen sich in Sekunden mit recent_authentication_lifetime und very_recent_authentication_lifetime konfigurieren. Eine abgewiesene Prüfung führt standardmäßig zu HTTP 403.

ReAuthenticationEntryPointInterface erlaubt die Weiterleitung zu einer Passwortbestätigung und danach zurück zur ursprünglichen Aktion. Eine Firewall verwendet dafür re_authentication_entry_point. Der OIDC-Authenticator implementiert dieses Interface und kann den Benutzer mit prompt=login erneut zum Provider schicken. Symfony wertet außerdem den auth_time-Claim des ID-Tokens aus. Eine lautlose Anmeldung in einer alten Providersitzung gilt daher nicht als frische Authentifizierung. Tokens speichern verwendete Authentifizierungsmethoden und deren letzte Zeitpunkte. Die Bezeichnungen folgen RFC 8176, OIDC liest sie aus amr, eigene Authenticatoren können sie über AuthenticationMethodBadge setzen. Ein eigener Trust Resolver kann zum Beispiel AuthenticationMethod::HARDWARE_KEY innerhalb von fünf Minuten verlangen.

Symfony 8.2 enthält außerdem einen nativen oidc_login-Authenticator für den OpenID-Connect-Authorization-Code-Flow. Mathieu Santostefano leitete diese Arbeit. Benötigt werden symfony/http-client und web-token/jwt-library. Die Provider-Endpunkte stammen aus .well-known/openid-configuration. Geschützte Seiten leiten zum Provider weiter, der standardmäßig nach /oidc/callback zurückkehrt. Das Symfony-Flex-Rezept importiert die Login-Routen, darunter _oidc_login_start_main. State und Nonce schützen den Ablauf, PKCE ist standardmäßig aktiv. Signaturen der ID-Tokens werden gegen zwischengespeicherte JWKS-Schlüssel geprüft. Symfony validiert iss, aud, exp, iat und den iss-Wert der Antwort. Provider-Endpunkte müssen HTTPS verwenden. Eine Ausnahme bilden Loopback-Hosts in der lokalen Entwicklung. Weiterleitungen werden nicht automatisch verfolgt.

Der eingebaute OIDC-Provider kann Benutzer aus Claims erzeugen. Ein eigener AttributesBasedUserProviderInterface-Provider erhält alle Claims als zweites Argument von loadUserByIdentifier(). user_identifier_claim kann etwa email als Kennung festlegen. user_data_source kann die Claims aus dem ID-Token lesen. Der UserInfo-Endpunkt wird dann nicht abgefragt. Statische Zusatzparameter kommen über authorization_params, anfrageabhängige Parameter über OidcAuthorizationRequestEvent. Für die Clientauthentifizierung stehen client_secret_basic, client_secret_post, client_secret_jwt, private_key_jwt und none bereit. Refresh-Tokens, Provider-Logout und max_age werden ebenfalls unterstützt. oidc_login setzt bewusst kein Remember-me-Badge, weil der Provider die Anmeldung kontrolliert. max_age oder prompt=login steuert ihre Aktualität.

Messenger erhält Optionen für eine Transaktions-Outbox und für Claim Check. Die Outbox speichert Nachrichten zunächst in einem Doctrine-Transport mit derselben Datenbankverbindung wie die Anwendung. Ein Relay leitet sie danach an AMQP, Amazon SQS oder einen anderen Ziel-Broker weiter. Eine typische Konfiguration verwendet den Speicherdienst db_outbox mit doctrine://default?queue_name=outbox. Separate Worker laufen mit messenger:consume db_outbox und messenger:consume orders. Verzögerungen gelten bereits in der Outbox. Fehler beim Weiterleiten nutzen deren Retry- und Failure-Transport, Fehler bei der Verarbeitung den Ziel-Transport. Die Reihenfolge weitergeleiteter Nachrichten ist nicht garantiert.

claim_check legt Nachrichten oberhalb einer konfigurierten Größe in einem PSR-6-Pool ab. Für die Größe zählen Body und Header der kodierten Nachricht. Der Transport übergibt eine zufällige Kennung und eine Prüfsumme. Der Worker lädt die Nachricht, prüft sie und verarbeitet sie normal. Unterstützt werden unter anderem Redis, Valkey, Memcached, PDO und Doctrine DBAL. Alle Produzenten und Konsumenten müssen denselben eigenen Pool erreichen können. Seine Lebensdauer muss Verzögerungen, Wiederholungen und die Aufbewahrung im Failure-Transport abdecken. Ein abgelaufener Claim erzeugt ClaimCheckNotFoundException innerhalb von MessageDecodingFailedException und folgt dem normalen Retry-Weg.

Der Serializer macht SerializedName und SerializedPath wiederholbar und erlaubt Gruppen an diesen Attributen. YAML- und XML-Mappings unterstützen die Änderung ebenfalls. Eine Property kann damit für Gruppen wie api_v1 und api_v2 unterschiedliche Namen erhalten. AbstractNormalizer::IGNORED_GROUPS und withIgnoredGroups() schließen bestimmte Gruppen nur für einen Kontext aus. #[Ignore] entfernt eine Property weiterhin generell. Eine optionale Kontextoption führt die Validator-Konvention der Gruppe Default im Serializer ein. Benannte Serializer lassen sich nun MapRequestPayload, MapQueryString, Serialize und Messenger zuordnen. Eine API kann snake_case nutzen, während messenger.transport.symfony_serializer einen eigenen Service verwendet. Validierungsfehler mit HTTP 422 verwenden weiterhin den Default-Serializer. Ihre Property-Pfade berücksichtigen den Name Converter des benannten Serializers nicht.

Die experimentelle KeyManagement-Komponente vereinheitlicht den Zugriff auf AWS KMS, Azure Key Vault, Google Cloud KMS und HashiCorp Vault. symfony/key-management enthält Interfaces, Envelope-Verschlüsselung sowie lokale Backends für libsodium und OpenSSL. Die Provider-Bridges heißen symfony/aws-key-management, symfony/azure-keyvault-key-management, symfony/google-cloud-key-management und symfony/hashicorp-vault-key-management. Die Entwicklungsversion lässt sich mit composer require symfony/key-management:^8.2@dev installieren.

Direkte Verschlüsselung sendet die Daten an den KMS und eignet sich für kleine Werte. AWS KMS begrenzt diesen Weg auf 4 KB. Envelope-Verschlüsselung fordert einen Datenschlüssel an, verschlüsselt lokal mit AES-256-GCM und legt den geschützten Schlüssel zusammen mit dem Ciphertext ab. Die Anwendung verarbeitet nur eine Kennung wie Alias oder ARN und nie den Master-Key. Clients werden unter key_management über DSNs definiert. Für die Entwicklung kann ein sodium-Client einen Inline-Schlüssel verwenden. EnvelopeEncrypterInterface, EncrypterInterface und DecrypterInterface stellen die Services bereit. #[Target] wählt einen anderen als den Standard-Client. Die Komponente liefert key-management:encrypt, key-management:decrypt, key-management:generate-data-key und key-management:rewrap-data-keys. Die Web-Debug-Toolbar zeigt die Aufrufe der KMS-Clients.

Doctrine-Bridges ergänzen EncryptedType und das Attribut BlindIndexed für die Suche in verschlüsselten Spalten. Die Verschlüsselung erzeugt zufällige Ciphertexte, deshalb speichert der Index einen Digest mit Schlüssel für Suchvorgänge. Ein Email-Index-Service benötigt einen KMS-Client und einen mit key-management:generate-data-key erzeugten geschützten Schlüssel. Anwendungen registrieren ihre verschlüsselten Doctrine-Typen über einen EncryptedTypes-Service beim Kernel-Boot. Die DBAL-Bridge kann Datenschlüssel in einer Tabelle ablegen. In jeder Zeile steht dann eine 16-Byte-Referenz, und der KMS wird einmal je Datenschlüssel aufgerufen. Rewrapping verschiebt Schlüssel zu einem anderen Master-Key oder Provider, ohne die verschlüsselten Daten neu zu schreiben.

Weitere angekündigte Änderungen betreffen PGP/MIME mit PgpSigner und PgpEncrypter. S/MIME erhält on_missing_certificate. Der Standardwert send_unencrypted ist veraltet, Symfony 9.0 wirft dafür eine Exception. Hinzu kommen ein generiertes JSON Schema für die Konfiguration, Wildcards in der Rollenhierarchie mit debug:roles, Profiler-Diagramme, getrennte Cache-Regeln für CDN und Browser, Cache-Statusinformationen, schnellere Messenger-Worker mit paralleler Verarbeitung und AMQP-Verbesserungen, provider-gehostete E-Mail-Templates mit Tracking-Steuerung sowie Performance-Arbeiten für Web, APIs, Console, Entwicklung und Cache-Builds. Die Symfony-Blogreihe Living on the edge sammelt die Ankündigungen.