Routes, contrôleurs et résolution d’arguments

Comprendre le mécanisme

Une route associe chemin, paramètres et contraintes à un contrôleur. Les méthodes HTTP, hôtes ou requirements réduisent les correspondances autorisées. Une valeur par défaut n’est pas une validation métier. Les noms de routes servent à générer des URL indépendamment de la forme du chemin. Le contrôleur traduit le protocole vers les services applicatifs et retourne une réponse, sans absorber toute la logique métier.

Raisonner et vérifier

Un argument résolu automatiquement n’est pas nécessairement autorisé pour l’acteur courant. Vérifiez séparément format, existence et accès à la ressource. Une route statique peut entrer en conflit avec un paramètre générique ; les priorités et contraintes doivent rendre la sélection prévisible. Testez aussi les méthodes refusées et la locale utilisée par la génération de liens.

Une méthode de route n’est pas une permission

Restreindre une route à POST évite certains appels incompatibles avec son contrat HTTP. Cela ne prouve pas que l’acteur possède la réservation visée ni que la transition est permise. Placez les contrôles d’identité, d’objet et d’état avant la mutation. Un test doit essayer une méthode refusée et un acteur interdit séparément : les deux échecs n’ont pas la même cause.

Un paramètre reste une entrée à interpréter

Un identifiant fourni par le chemin sélectionne une ressource, mais n’établit pas le droit de la consulter. Une résolution automatique en argument de contrôleur ne change pas cette frontière. Vérifiez l’existence puis le périmètre autorisé selon le modèle choisi. L’application doit refuser une ressource tierce même si son identifiant est correctement formé et si l’objet a été chargé sans erreur.

Contraindre la forme avec un requirement

Un requirement limite les formes de valeurs que le routeur reconnaît pour un paramètre. Il ne vérifie pas tous les invariants du domaine ni les permissions. Un nombre conforme peut encore désigner une ressource absente ou interdite. Utilisez le routage pour exprimer son contrat de correspondance, puis gardez la validation et l’autorisation au niveau où leur sens est connu.

Générer une URL depuis le contrat de route

Utiliser un nom de route découple les liens de la forme concrète du chemin. Le contexte de génération, notamment hôte et schéma pour une URL absolue, doit rester maîtrisé. Une valeur Host reçue librement ne doit pas devenir une origine publique fiable sans politique adaptée. Les tests doivent vérifier le lien rendu dans le contexte réellement utilisé, pas seulement l’existence d’un nom dans la configuration.

La localisation fait partie du chemin

Des routes localisées peuvent produire des URL différentes pour une même fonction. Traduire seulement le libellé visible ne modifie pas automatiquement chaque chemin. Générez les liens selon le contexte de locale attendu et testez la navigation dans les deux interfaces. Un changement de langue doit conduire à la ressource prévue, sans perdre silencieusement l’identifiant ou une étape importante du parcours.

Existence et non-divulgation

Une ressource absente peut produire un 404 selon le contrat de l’API. Une ressource existante n’est pas pour autant lisible par tout acteur. La politique publique peut aussi limiter les différences qui divulgueraient son existence. Séparez ce que le client reçoit de ce que le diagnostic privé conserve. Dans tous les cas, le refus ne doit pas arriver après la distribution des données protégées.

Comprendre les collisions de correspondance

Deux routes de formes proches peuvent demander des contraintes ou une priorité pour exprimer l’intention. Un segment fixe comme examen ne doit pas être traité par erreur comme un nom de leçon si une route spécialisée est prévue. Testez les chemins limites et les méthodes. Une correspondance nominale ne démontre pas que toutes les routes voisines sont résolues selon le contrat voulu.

Le contrôleur construit un résultat observable

Le nom d’une action ne garantit ni son statut ni ses effets. Définissez la réponse attendue pour succès, entrée invalide, absence et refus de permission. Les composants peuvent intervenir avant ou après l’action ; le test doit donc observer le message final et le non-effet des chemins interdits. Un contenu HTML correct n’est pas une preuve suffisante d’une méthode ou d’une autorisation correctement contrôlée.

Limiter les destinations de retour

Une URL de retour reçue d’un client ne doit pas permettre une redirection arbitraire vers un destinataire non admis. Définissez des destinations maîtrisées et comparez les composants avec un parseur adapté. Le texte visuel d’un domaine n’établit pas sa confiance. Si une redirection préserve méthode et corps, examinez aussi la diffusion de données sensibles avant de suivre le saut.

Tester les méthodes non prises en charge

Une route correspondant au chemin peut refuser une méthode et produire un 405 selon la résolution du routeur. Ce cas ne se confond pas avec une ressource métier inexistante. Préparez les demandes GET, POST ou autres pertinentes et vérifiez le statut ainsi que l’absence d’effet. Une interface qui ne montre qu’un bouton ne limite pas les méthodes qu’un client direct peut essayer.

Atelier guidé : lire, expliquer et vérifier le code

<?php
declare(strict_types=1);
use Symfony\Component\Routing\Attribute\Route;
final class LabController {
    #[Route('/lab/orders/{id}/cancel', methods: ['POST'])]
    public function cancel(string $id): void {}
}

L’attribut de route de l’atelier déclare que l’action correspond à POST sur un chemin donné. L’identifiant reste une donnée de sélection fournie par l’appelant. Rien dans cet attribut n’établit que ce dernier possède la réservation, et l’action vide ne fournit pas une règle d’accès. Il faut donc ajouter l’autorisation au parcours effectif avant l’annulation.

Écrivez un test avec deux comptes et une réservation appartenant au premier. Le second doit être refusé même en utilisant exactement la méthode et la forme de route attendues. Ajoutez un test de méthode incorrecte pour montrer une autre frontière. Ces deux preuves empêchent de considérer qu’un routage strict remplace la connaissance des droits métier sur l’objet.