Development

Documentation/fr_FR/askeet/trunk/D6

You must first sign up to be able to contribute.

Version 2 (modified by mikael.randy, 10 years ago)
1ere traduction

Cette partie de la documentation est en cours de traduction. Cela signifie qu'elle est traduite de manière soit incomplète, soit inexacte. En attendant que cette traduction soit terminée, vous pouvez consulter la version en anglais pour des informations plus fiables.

Calendrier de l'avent sixième jour: Sécurité et validation de formulaire

Précédemment dans Symfony

Au cours du cinquième jour, vous avez dû manipuler les templates et les actions. Les formulaires et les pagineur n'ont plus aucun secret pour vous. Mais après avoir construit le formulaire de connexion, vous attendez surement de nous que nous vous montrions comment restreindre l'accès à certaines fonctionnalités pour les membres non-authorisés. C'est ce que nous allons réaliser aujourd'hui, a l'aide de plusieurs validation de formulaires. Comme nous allons également ajouter des classes personnelles à l'application, vous devriez également comprendre les concepts exposés dans le chapitre concernant les extensions personnelles dans le livre Symfony.

Validation du formulaire de connexion

Fichier de validation

Le formulaire de connexion dispose de deux champs : nickname et password Mais que doit-il se passer si l'utilisateur soumets des données incorrectes ? Pour gérer ce cas de figure, vous devez créer un fichier login.yml dans le répertoire /frontend/modules/user/validate (Notez que login est le nom de l'action dont le formulaire doit être validé). Ajouter le contenu suivant à ce fichier :

methods:
  post: [nickname, password]

names:
  nickname:
    required:     true
    required_msg: your nickname is required
    validators:   nicknameValidator

  password:
    required:     true
    required_msg: your password is required

nicknameValidator:
    class:        sfStringValidator
    param:
      min:        5
      min_error:  nickname must be 5 or more characters

Premièrement, sous l'entête methods, vous devez lister les champs à valider pour la méthode du formulaire (nous ne définissons ici que la méthode POST car les données GET ne sont utilisées que pour afficher le formulaire et n'ont pas besoin d'être validée). Puis, sous l'entête names, les critères de validation de chaque champs à valider sont listés, suivi du message d'erreur correspondant. Eventuellement, à l'image du champs nickname, il est possible de définir des règles de validation spécifiques, sous l'entête correspondant au nom de cette règle. Dans cet exemple, le sfStringValidator est un validateur proposé par symfoy qui valide le format d'une chaine de caractères (les validateurs par défaut proposés par Symfony sont détaillés dans le chapitre exposant comment valider un formulaire dans le livre Symfony)

Gestionnaire d'erreur

Maintenant, qu'est-il sensé se passer si un utilisateur valide des données invalides ? Les conditions écrites dans le fichier login.yml ne seront pas satisfaites, et le controleur de symfony va transmettre la requête à la méthode handleErrorLogin de la classe userActions - à l'image de la méthode executeLogin(), tel que défini dans l'argument de la balise form_tag. Si cette méthode n'existe pas, le comportement par défaut est d'afficher le template loginError.php. La raison de ce comportement est que la méthode handleError() d'origine retourne :

[php] public function handleError() { return sfView::ERROR; }

Nous avons un nouveau gabarit à écrire. Or, il serait préférable de ré-afficher le formulaire de connexion , avec les messages d'erreur affichés près des champs invalides. Donc, nous allons modifier le comportement de l'erreur de connexion pour afficher le template loginSuccess.php en cas d'erreur.

[php] public function handleErrorLogin() { return sfView::SUCCESS; }

NOTE La convention de nommage qui lie le nom de l'action, sa valeur de retour et le nom du fichier template est détaillée dans le chapitre concernant la couche "Vue" du livre Symfony