password - Symfony 2 SecurityContext class obsoleta

symfony hash

Question

Recibo el siguiente error cuando trato de llegar a la aplicación / ejemplo en la demo de Symfony

Error: la clase Symfony / Component / Security / Core / SecurityContext está en desuso desde la versión 2.6 y se eliminará en 3.0. Use Symfony / Component / Security / Core / Authentication / Token / Storage / TokenStorage o Symfony / Component / Security / Core / Authorization / AuthorizationChecker en su lugar.

Sin embargo, el servidor devuelve la respuesta correcta con un código de estado 200.

No he encontrado nada en Google al respecto. ¿Alguien ha encontrado este error antes y / o sabe cómo solucionarlo?

Answer 1

No es un error propio, solo una advertencia.

Una clase obsoleta es una clase que se planea eliminar en futuras versiones (de Symfony, en este caso).

Sugiere que dejes de usarlo y te TokenStorage clase más nueva (y sustitutiva), TokenStorage y AuthorizationChecker , que se completará completamente para realizar las mismas tareas.

Answer 2

Se vuelve tan molesto ver esa advertencia. Al mismo tiempo, no quiere apagar las advertencias. Así que pensé que quizás sería útil dar un ejemplo de cómo cambiar tu código para deshacerte de él. Así es como cambié la clase OAuthUtils para hacerlo. Primero, cambié /vendor/hwi/oauth-bundle/HWI/Bundle/OAuthBundle/Resources/config/oauth.html de esto:

<service id="hwi_oauth.security.oauth_utils" class="%hwi_oauth.security.oauth_utils.class%">
<argument type="service" id="security.http_utils" />
<argument type="service" id="security.context" />
<argument>%hwi_oauth.connect%</argument>
</service>

a esto:

<service id="hwi_oauth.security.oauth_utils" class="%hwi_oauth.security.oauth_utils.class%">
<argument type="service" id="security.http_utils" />
<argument type="service" id="security.authorization_checker" />
<argument>%hwi_oauth.connect%</argument>
</service>

Ahora tenemos que cambiarlo en la clase /vendor/hwi/oauth-bundle/HWI/Bundle/OAuthBundle/Security/OAuthUtils desde aquí:

use Symfony/Component/Security/Core/SecurityContextInterface; ... /** * @var SecurityContextInterface */ private $securityContext; /** * @param HttpUtils $httpUtils * @param SecurityContextInterface $securityContext * @param boolean $connect */ public function __construct(HttpUtils $httpUtils, SecurityContextInterface $securityContext, $connect) { $this->httpUtils = $httpUtils; $this->securityContext = $securityContext; $this->connect = $connect; }

a esto:

use Symfony/Component/Security/Core/Authorization/AuthorizationChecker; ... /** * @var AuthorizationChecker */ private $authorizationChecker; /** * @param HttpUtils $httpUtils * @param AuthorizationChecker $authorizationChecker * @param boolean $connect */ public function __construct(HttpUtils $httpUtils, AuthorizationChecker $authorizationChecker, $connect) { $this->httpUtils = $httpUtils; $this->authorizationChecker = $authorizationChecker; $this->connect = $connect; }

Luego hice cambios donde se usó el securityContext . Reemplazado con authorizationChecker .

public function getAuthorizationUrl(Request $request, $name, $redirectUrl = null, array $extraParameters = array()) { $resourceOwner = $this->getResourceOwner($name); if (null === $redirectUrl) { if (!$this->connect || !$this->authorizationChecker->isGranted(''IS_AUTHENTICATED_REMEMBERED'')) { $redirectUrl = $this->httpUtils->generateUri($request, $this->ownerMap->getResourceOwnerCheckPath($name)); } else { $redirectUrl = $this->getServiceAuthUrl($request, $resourceOwner); } } return $resourceOwner->getAuthorizationUrl($redirectUrl, $extraParameters); }

El motivo de reemplazar SecurityContext con AuthorizationChecker es que solo se usa el método Garantizado en este caso. Tal vez podrías reemplazarlo con TokenStorage o usar tanto AuthorizationChecker como TokenStorage si lo necesitas para tu caso.

Answer 3

Explicación

Comenzando con Symfony 2.6, el SecurityContext se dividió en TokenStorage y AuthorizationChecker (ver: Symfony Blog - "Nuevo en Symfony 2.6: mejoras en los componentes de seguridad" ).

La razón principal de esto fue para evitar la referencia circular que se producía con bastante frecuencia al inyectar el SecurityContext en sus propios servicios.

Solución

El cambio en sí mismo es 100% compatible con versiones anteriores (como se indica en la publicación de blog vinculada), solo necesita volver a escribir cómo accedió al SecurityContext .

// Symfony 2.5
$user = $this->get(''security.context'')->getToken()->getUser();
// Symfony 2.6
$user = $this->get(''security.token_storage'')->getToken()->getUser();
// Symfony 2.5
if (false === $this->get(''security.context'')->isGranted(''ROLE_ADMIN'')) { ... }
// Symfony 2.6
if (false === $this->get(''security.authorization_checker'')->isGranted(''ROLE_ADMIN'')) { ... }

Simplemente puede tratar de encontrar al culpable haciendo una búsqueda de texto para security.context o SecurityContext en su código fuente (incluido el directorio del proveedor).

Pero como dijiste que estás usando Symfony 2.6 vainilla, parece que simplemente usa algunos métodos que pronto serán obsoletos. Entonces, simplemente podrías usar esto ...

Solución

Como Symfony lo hace E_USER_DEPRECATED activar los errores E_USER_DEPRECATED , puedes simplemente deshabilitarlos al arrancar tu Symfony AppKernel :

// app/AppKernel.php
class AppKernel extends Kernel
{
public function __construct($environment, $debug) {
// Keep error reporting like it was and disable only deprecation warnings.
error_reporting(error_reporting() & (-1 ^ E_DEPRECATED));
// ...
}
}

Personalmente me gustan las advertencias de depreciación, porque los registros de cambios de Symfony tienden a brindar información muy detallada sobre cómo se necesita cambiar el código para admitir versiones futuras de Symfony y las advertencias de desactivación normalmente se activan meses antes de que los métodos realmente se desaprovechen.