Symfony2 est_granté ('IS_AUTHENTICATED_FULLY') lors de l'affichage de la page d'erreur 404, provoquant une exception ResourceNotFoundException
J'ai configuré des pages d'erreur personnalisées à afficher pour certaines erreurs HTTP dans le dossier:
app/Resources/TwigBundle/views/Exception/
La page 403 (error403.html.twig) fonctionne et s'affiche comme prévu.
La page 500 (error500.html.twig) fonctionne et s'affiche comme prévu.
La page 404 (error404.html.twig) génère une erreur de serveur 500:
Erreur irrécupérable PHP: exception non capturée 'Symfony\Component\Routing\Exception\ResourceNotFoundException'
L'erreur est générée en effectuant une vérification d'authentification pour afficher certains éléments de menu pour les utilisateurs authentifiés ou non:
{% if is_granted('IS_AUTHENTICATED_FULLY') %}
Si je supprime cette vérification et permets uniquement l'affichage de tous les éléments de menu, la page charge la page d'erreur comme prévu. Encore une fois, la page 403 s'affiche comme il se doit et utilise les contrôles d'authentification sans problème.
Je suis coincé sur celui-ci. Les pages sont EXACTEMENT les mêmes, à part le nom de fichier.
Vous ne pouvez pas utiliser le is_granted dans une page 404 depuis la version 2.1:
C'est mentionné dans le fichier de mise à jour
L'écouteur de pare-feu est maintenant enregistré après l'écouteur de routeur. Cela signifie que les URL de pare-feu spécifiques (telles que/login_check et/logout) doivent désormais avoir des itinéraires appropriés définis dans votre configuration de routage. De même, si vous avez une page d'erreur 404 personnalisée, assurez-vous de ne pas utiliser de fonctionnalités liées à la sécurité, telles que
is_granted.
Voir: https://github.com/symfony/symfony/blob/master/UPGRADE-2.1.md#security
Si symfony <2.8:
{% if app.user is not null and is_granted('ROLE_ADMIN') %}
Voir: https://github.com/symfony/symfony-docs/issues/2078
Éditer du 17 décembre 15:
Ce n'est plus nécessaire depuis la 2.8,
{% if is_granted('ROLE_ADMIN') %}
fonctionne bien maintenant.
Je suggérerais de vérifier que app.security.token soit plus strict et d’évaluer true même lorsque l’utilisateur est anonyme.
Si vous recherchez app.user, il évaluera false dans les modèles d'exception, mais même lorsque le pare-feu est présent (= modèle standard) mais que l'utilisateur n'est pas connecté. Cela empêchera, par exemple, l’affichage d’un bouton de connexion.