Impossible d'accéder à deux de mes routes

Présentes et matchées en CLI, mais déclenche une 404 puis une 500 en HTTP

Le problème exposé dans ce sujet a été résolu.

Bonjour à tous !

J’écris ceci parce qu’il y a quelque chose qui me bloque ce matin, et en fait depuis hier soir.

J’ai ajouté deux contrôleurs dans chacun desquels j’ai une route, au format annotation. Ces deux routes sont bien listées quand je fais un debug:router, et quand je fais un router:match, elles sont bien reconnues.

Ces deux routes sont très similaires, en voici une :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
<?php
/**
 * @Route("/{_locale}/chose/{idChose}")
 */
class TrucController extends Controller
{
    /**
     * @Route(path="/trucs/list", name="trucs_list")
     * @param Request $request
     * @param integer $idChose
     */
    public function listAction(Request $request, $idChose)
    {
La définition d’une des routes. Pour l’autre, il suffit de remplacer "truc" par "machin"  :p

Maintenant, quand je tente d’y accéder par navigateur, je n’ai pas même une 500 Symfony, mais une 500 de composant Symfony, soit la page avec les blocs gris uniquement. Dans l’ordre d’affichage (et donc l’inverse de celui des exceptions capturées), j’ai :

  • une AuthenticationCredentialsNotFoundException (3/3)
  • une NotFoundHttpException (2/3)
  • une ResourceNotFoundException (1/3)

Quand cette erreur survient, je suis connecté en tant que super administrateur.

Vu que c’est probablement lié à ma configuration de firewall, je vous la mets ci-dessous.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
security:
    encoders:
        FOS\UserBundle\Model\UserInterface: bcrypt

    role_hierarchy:
        ROLE_APPLICATION:  ROLE_USER
        ROLE_ADMIN:        ROLE_APPLICATION
        ROLE_SUPER_ADMIN:  ROLE_ADMIN, ROLE_ALLOWED_TO_SWITCH

    providers:
        fos_userbundle:
            id: fos_user.user_provider.username_email

    firewalls:
        main:
            pattern: ^/
            form_login:
                provider: fos_userbundle
                login_path: fos_user_security_login
                check_path: fos_user_security_check
                success_handler: redirect.after.login
            logout:
                path:   fos_user_security_logout
                success_handler: redirect.after.logout
            anonymous:    true

    access_control:
        - { path: ^/_wdt, roles: IS_AUTHENTICATED_ANONYMOUSLY }         # allow wdt for debugging
        - { path: ^/_profiler/, role: IS_AUTHENTICATED_ANONYMOUSLY }    # allow profiler for debugging
        - { path: ^/bundles/, role: IS_AUTHENTICATED_ANONYMOUSLY }      # allow assets to be loaded anonymously

        - { path: ^/[a-z]+/login$, role: IS_AUTHENTICATED_ANONYMOUSLY }
        - { path: ^/[a-z]+/change, role: IS_AUTHENTICATED_ANONYMOUSLY }
        - { path: ^/[a-z]+/register, role: IS_AUTHENTICATED_ANONYMOUSLY }
        - { path: ^/[a-z]+/resetting, role: IS_AUTHENTICATED_ANONYMOUSLY }

        - { path: ^/api, role: IS_AUTHENTICATED_ANONYMOUSLY }

        # Remember that paths here are regexes, not just URLs
        - { path: ^/[a-z]+/register/confirm, role: ROLE_USER } # Allow new users to confirm registration
        - { path: ^/[a-z]+/thing/new, role: ROLE_USER }        # Allow new users to access the thing creation form
        - { path: ^/[a-z]+/profile, role: ROLE_USER }          # Allow new users to access their profile and edit it

        - { path: ^/admin, role: ROLE_ADMIN }
        - { path: ^/, role: ROLE_APPLICATION } # this must be the last match, as url patterns are checked in the order they appear
security.yml

Merci d’avance  :)

OK, bon, on est bientôt le week-end.

C’est tout un concours de cache navigateur et de réponse serveur qui a fait que pendant un temps, j’ai eu l’affichage d’erreur, puis j’entrais dans un cas où je retournais une 204… Et dans ce cas, le navigateur ne met pas à jour ce qui est affiché…

+0 -0

Alors je ne vais pas (encore [NdE : dans le sens de maintenant]) fournir les stack traces parce que c’est probablement inutile (et que je devrais les nettoyer), mais c’est vrai que je peux au moins compléter les messages d’erreur  :ange:

AuthenticationCredentialsNotFoundException in classes.php line 5490:
The token storage contains no authentication token. One possible reason may be that there is no firewall configured for this URL.

3/3

NotFoundHttpException in classes.php line 4171:
No route found for "GET /fr/chose/1/truc/list"

2/3

ResourceNotFoundException in appDevDebugProjectContainerUrlMatcher.php line 949:

1/3

Et ce alors que, comme mentionné dans le premier message, la route est bien matchée si je la "teste" en ligne de commandes avec router:match.

Quant à la version exacte de Symfony, je suis en 3.2.1, mais m’est avis que ce n’est pas à ce point spécifique à la version.

Edit

Dans appDevDebugProjectContainerUrlMatcher.php, j’ai bien ceci, de manière similaire pour les deux routes :

1
2
3
4
<?php   // trucs_list
        if (preg_match('#^/(?P<_locale>[^/]++)/chose/(?P<idChose>[^/]++)/trucs/list$#s', $pathinfo, $matches)) {
            return $this->mergeDefaults(array_replace($matches, array('_route' => 'trucs_list')), array (  '_controller' => 'My\\WonderfulBundle\\Controller\\TrucController::listAction',));
        }
+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte