Symfony 8.2 está previsto para finales de noviembre de 2026 y tendrá soporte hasta julio de 2027. Requiere PHP 8.4.0 o posterior. La rama sigue en desarrollo, por lo que sus APIs pueden cambiar antes de la publicación definitiva. Los ejemplos deben probarse fuera de producción.

<?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
    {
    }
}

Cada componente de Symfony incluirá su propio bundle, configuración y servicios. Symfony 8.2 incorpora 29 bundles, entre ellos CacheBundle, HttpClientBundle, MailerBundle y MessengerBundle. La instalación registra automáticamente el bundle y no exige cambios en config/bundles.php. Las claves framework.* existentes continúan funcionando sin deprecaciones. La raíz framework puede eliminarse de forma gradual. framework.assets pasa a ser asset, framework.translator pasa a translation y framework.workflows pasa a workflow. Lock y semaphore aceptan directamente una DSN. La inspección de configuración usa debug:config mailer en lugar de debug:config framework mailer. Los formularios ya no activan la validación automáticamente. La instalación de symfony/validator se encarga de ello. RedirectController se mueve a Routing y TemplateController a TwigBundle. Los servicios de los bundles se crean bajo demanda, así que los registros adicionales no aumentan el coste de las peticiones. FrameworkBundle seguirá siendo el núcleo HTTP.

Los autores de bundles reciben los métodos ConfigBuilder aliasOf() y appendFromCallback(). aliasOf() dirige un nodo raíz a la configuración de otra extensión, lo que mantiene compatible framework.workflows cuando workflow pertenece al componente Workflow. appendFromCallback() añade nodos desde un callback y conserva la cadena fluida. Las clases trasladadas desde FrameworkBundle quedan obsoletas.

La seguridad incorpora una reautenticación similar al modo sudo. IS_AUTHENTICATED_RECENTLY acepta por defecto una autenticación realizada durante las dos horas anteriores. IS_AUTHENTICATED_VERY_RECENTLY limita el periodo a cinco minutos. Los controles funcionan en access_control, Twig y los atributos de los controladores. Las expresiones de seguridad añaden is_recently_authenticated() y is_very_recently_authenticated(). Una cookie remember-me no supera ninguno de los dos controles. Los periodos se configuran en segundos mediante recent_authentication_lifetime y very_recent_authentication_lifetime. Un control rechazado devuelve HTTP 403 de forma predeterminada.

ReAuthenticationEntryPointInterface permite redirigir al usuario a una pantalla de confirmación de contraseña y devolverlo después a la acción original. El firewall usa la opción re_authentication_entry_point. El autenticador OIDC implementa esta interfaz y puede enviar al usuario de nuevo al proveedor con prompt=login. Symfony también comprueba el claim auth_time del ID token. Una autenticación silenciosa con una sesión antigua del proveedor no cuenta como reciente. Los tokens guardan los métodos de autenticación usados y sus últimos momentos de uso. Los nombres siguen RFC 8176, OIDC los obtiene del claim amr y los autenticadores personalizados pueden declararlos con AuthenticationMethodBadge. Un trust resolver propio puede exigir AuthenticationMethod::HARDWARE_KEY durante los cinco minutos anteriores.

Symfony 8.2 añade un autenticador oidc_login nativo para el flujo Authorization Code completo de OpenID Connect. Mathieu Santostefano dirigió el trabajo. Se necesitan symfony/http-client y web-token/jwt-library. Symfony obtiene los endpoints del proveedor desde .well-known/openid-configuration. Una página protegida redirige al proveedor, que vuelve por defecto a /oidc/callback. La receta de Symfony Flex importa las rutas de login, incluida _oidc_login_start_main. State y nonce protegen el flujo, PKCE viene activado y las firmas de los ID tokens se validan contra claves JWKS almacenadas en caché. Symfony comprueba iss, aud, exp, iat y el valor iss de la respuesta. Los endpoints deben usar HTTPS, salvo los hosts loopback durante el desarrollo local. No se siguen redirecciones.

El proveedor OIDC integrado puede crear usuarios a partir de sus claims. Un proveedor propio que implemente AttributesBasedUserProviderInterface recibe todos los claims como segundo argumento de loadUserByIdentifier(). user_identifier_claim permite usar un claim como email para identificar al usuario. user_data_source puede seleccionar el ID token en lugar de UserInfo. authorization_params añade parámetros estáticos y OidcAuthorizationRequestEvent permite calcular parámetros según la petición. La autenticación del cliente admite client_secret_basic, client_secret_post, client_secret_jwt, private_key_jwt y none. También se contemplan refresh tokens, logout del proveedor y max_age. oidc_login no añade deliberadamente un badge remember-me, porque la autenticación pertenece al proveedor. max_age o prompt=login permite controlar su antigüedad.

Messenger incorpora una opción outbox y otra llamada claim_check. La outbox guarda primero el mensaje en un transporte Doctrine que comparte la conexión de base de datos con la aplicación. Después, un relay lo envía a AMQP, Amazon SQS u otro broker de destino. Una configuración habitual usa db_outbox con doctrine://default?queue_name=outbox. Se ejecutan workers separados con messenger:consume db_outbox y messenger:consume orders. El retraso se aplica dentro de la outbox. Los errores de reenvío usan la estrategia de reintento y el failure transport de la outbox. Los errores de procesamiento usan los del transporte final. El orden de los mensajes reenviados no está garantizado.

claim_check almacena en un pool PSR-6 los mensajes que superan un tamaño codificado configurado. El cálculo incluye el cuerpo y las cabeceras. El transporte envía un identificador aleatorio y una suma de comprobación. El worker recupera el mensaje, comprueba la suma y lo procesa con normalidad. Se admiten pools de Redis, Valkey, Memcached, PDO y Doctrine DBAL. Productores y consumidores deben poder acceder al mismo pool dedicado. Su duración predeterminada debe cubrir retrasos, reintentos y el tiempo en el failure transport. Un claim caducado produce ClaimCheckNotFoundException dentro de MessageDecodingFailedException y sigue el flujo habitual de reintento.

El Serializer hace repetibles SerializedName y SerializedPath y permite asociarlos a grupos. Los mapeos YAML y XML también admiten esta configuración. Una propiedad puede tener nombres diferentes para grupos como api_v1 y api_v2. AbstractNormalizer::IGNORED_GROUPS y withIgnoredGroups() excluyen grupos concretos en un contexto. #[Ignore] continúa excluyendo siempre una propiedad. Una opción de contexto activa de forma explícita el grupo Default siguiendo la convención del Validator. Los serializers con nombre pueden asignarse ahora a MapRequestPayload, MapQueryString, Serialize y Messenger. La API puede usar snake_case con un serializer, y messenger.transport.symfony_serializer otro distinto. Las respuestas de validación HTTP 422 siguen usando el serializer predeterminado. Sus rutas de propiedades no aplican el name converter del serializer nombrado.

El componente experimental KeyManagement ofrece una API común para AWS KMS, Azure Key Vault, Google Cloud KMS y HashiCorp Vault. symfony/key-management contiene las interfaces, el cifrado envelope y backends locales basados en libsodium y OpenSSL. Los bridges son symfony/aws-key-management, symfony/azure-keyvault-key-management, symfony/google-cloud-key-management y symfony/hashicorp-vault-key-management. La versión de desarrollo se instala con composer require symfony/key-management:^8.2@dev.

El modo directo envía los datos al KMS y sirve para valores pequeños. AWS KMS establece un límite de 4 KB en ese modo. El cifrado envelope solicita una clave de datos, cifra localmente con AES-256-GCM y guarda la clave envuelta junto al ciphertext. La aplicación solo maneja un identificador, como un alias o un ARN, y nunca la clave maestra. Los clientes se configuran mediante DSN bajo key_management. En desarrollo se puede usar un cliente sodium con una clave inline. EnvelopeEncrypterInterface, EncrypterInterface y DecrypterInterface proporcionan los servicios. #[Target] selecciona un cliente que no sea el predeterminado. El componente añade key-management:encrypt, key-management:decrypt, key-management:generate-data-key y key-management:rewrap-data-keys. El web debug toolbar muestra las llamadas a cada cliente KMS.

Los bridges de Doctrine añaden EncryptedType y el atributo BlindIndexed para buscar columnas cifradas. El cifrado genera ciphertexts aleatorios, por lo que el índice guarda un digest con clave para realizar consultas. El servicio de índice Email necesita un cliente KMS y una clave envuelta creada con key-management:generate-data-key. Las aplicaciones registran sus tipos Doctrine cifrados mediante un servicio EncryptedTypes durante el arranque del kernel. El bridge DBAL puede guardar las claves de datos en una tabla. Cada fila almacena entonces una referencia de 16 bytes y el KMS se consulta una vez por clave. Rewrap permite trasladar las claves a otro master key o proveedor sin volver a escribir los datos cifrados.

Symfony también ha anunciado firma y cifrado PGP/MIME con PgpSigner y PgpEncrypter. S/MIME incorpora on_missing_certificate. Su valor predeterminado send_unencrypted está obsoleto, y Symfony 9.0 lanzará una excepción en ese caso. El resto de anuncios incluye un JSON Schema generado para la configuración, inspección de comodines en la jerarquía de roles mediante debug:roles, gráficos en el profiler, reglas de caché separadas para CDN y navegador, cabeceras Cache-Status, workers de Messenger más rápidos con procesamiento paralelo y mejoras de AMQP, plantillas de correo alojadas por el proveedor con controles de seguimiento y optimizaciones para páginas web, APIs, consola, desarrollo y construcción de caché. La serie Living on the edge del blog de Symfony reúne los anuncios.