La vérification des données est un composant clé de toute application Web. Il aide à prévenir les vulnérabilités de sécurité, la corruption des données et divers autres problèmes qui peuvent survenir lors de l'utilisation de l'entrée de l'utilisateur.
Cet article explorera ce qu'est la vérification des données et pourquoi elle est si importante. Nous comparerons la vérification côté client avec la vérification côté serveur et expliquerons pourquoi la vérification côté client ne devrait pas être invoqué.
Nous présenterons ensuite des règles de vérification pratiques que j'utilise couramment dans mon application Laravel. Enfin, nous apprendrons à créer nos propres règles de validation et à les tester pour nous assurer qu'ils fonctionnent comme prévu.
La vérification des données est un processus de vérification de la validité des données avant d'essayer de les utiliser. Cela peut être un élément simple pour vérifier, par exemple, que les champs obligatoires existent dans la demande, ou des vérifications plus complexes telles que si les champs correspondent à un modèle spécifique ou s'ils sont uniques dans la base de données.
Habituellement, lors de la vérification des données dans une application Web, si les données sont invalides, vous devez renvoyer un message d'erreur à l'utilisateur.
Cela aide à prévenir les vulnérabilités de sécurité, la corruption des données et améliore la précision des données. Par conséquent, nous continuerons à traiter la demande uniquement si les données sont valides.
N'oubliez pas, vous ne pouvez pas faire confiance aux données de l'utilisateur (au moins avant de les vérifier!).
Il existe de nombreuses raisons pour lesquelles la vérification des données est importante, notamment:
L'une des raisons les plus importantes de vérifier les données de votre application est d'améliorer la sécurité. En vérifiant les données avant de l'utiliser, vous pouvez réduire la possibilité que des entrées malveillantes soient utilisées pour attaquer votre application ou vos utilisateurs.
Imaginez que nous nous attendons à ce qu'un champ soit un entier, mais l'utilisateur passe un fichier. Cela peut causer divers problèmes lorsque nous essayons d'utiliser ces données ailleurs dans l'application.
pour donner un autre exemple, supposons que vous créez une application Web qui permet aux utilisateurs de voter sur le vote. Le vote ne peut être voté que entre AppModelsPoll le temps et le temps opens_at spécifié sur le modèle closes_at. Que se passe-t-il si quelqu'un définit accidentellement le temps closes_at avant le temps opens_at lors de la mise en place d'un vote? Selon la façon dont vous gérez cela dans votre application, cela peut causer divers problèmes.
En validant les données avant de les stocker au modèle, nous pouvons améliorer la précision des données dans notre application et réduire la possibilité de stocker des données incorrectes.
En plus de pouvoir vérifier les données réalisées dans les demandes HTTP, vous pouvez également vérifier la commande Artisan. Cela empêche les développeurs d'entrer accidentellement des valeurs non valides et de causer des problèmes avec l'application.
Habituellement, vous pouvez utiliser deux types de vérification dans votre application: la vérification côté client et la vérification côté serveur.
La vérification du client est la vérification effectuée dans le navigateur avant d'envoyer des données au serveur. Il peut être implémenté à l'aide d'attributs JavaScript ou même HTML.
Par exemple, nous pouvons ajouter une validation simple au champ Nombre en HTML pour nous assurer que le nombre saisi par l'utilisateur se situe entre 1 et 10:
<input type="number" min="1" max="10" required>
Ce champ de saisie a quatre pièces distinctes, qui sont utiles pour la vérification du client:
type="number": Cela indique au navigateur que l'entrée doit être un nombre. Sur la plupart des navigateurs, cela empêchera l'utilisateur de saisir autre chose que le nombre. Sur les appareils mobiles, il peut même faire apparaître un clavier numérique au lieu d'un clavier régulier, ce qui est très bénéfique pour l'expérience utilisateur. min="1": Cela indique au navigateur que le nombre entré doit être au moins 1. max="10": Cela indique au navigateur que le nombre entré doit être jusqu'à 10. required: Cela indique au navigateur que le champ est requis et doit être rempli avant de soumettre le formulaire. Dans la plupart des navigateurs, si l'utilisateur essaie de soumettre un formulaire avec une valeur non valide (ou aucune valeur), le navigateur bloquera la soumission du formulaire et affichera un message d'erreur ou une invite à l'utilisateur.
Ceci est très bénéfique pour guider les utilisateurs et améliorer l'expérience utilisateur globale de l'application. Mais c'est juste qu'il devrait être pris en compte: un guide. Vous ne devez pas vous fier uniquement à l'authentification du client comme la seule forme de vérification dans votre application.
Si quelqu'un ouvre les outils du développeur dans son navigateur, il peut facilement supprimer et contourner la vérification du client que vous avez définie.
De plus, il est important de se rappeler que lorsque les utilisateurs malveillants essaient d'attaquer votre application, ils utiliseront généralement des scripts automatisés pour envoyer des demandes directement à votre serveur. Cela signifie que la vérification du client que vous avez définie sera contournée.
La vérification côté serveur est une vérification qui s'exécute dans le backend d'application sur le serveur. Dans le contexte d'une application Laravel, il s'agit généralement d'une validation qui s'exécute dans un contrôleur ou une classe de demande de formulaire.
Étant donné que la vérification est sur votre serveur, l'utilisateur ne peut pas le modifier, c'est le seul moyen de vraiment s'assurer que les données envoyées au serveur sont valides.
Par conséquent, assurez-vous de toujours activer la vérification côté serveur dans votre application. Idéalement, chaque champ que vous essayez de lire à partir de la demande doit être vérifié avant d'essayer de l'utiliser pour effectuer une logique métier.
Maintenant que nous avons compris ce qu'est la vérification et pourquoi il est important, voyons comment l'utiliser dans Laravel.
Si vous utilisez Laravel depuis un certain temps, vous saurez que Laravel a un système de vérification incroyable intégré dans le cadre. Par conséquent, il est très facile de commencer avec la vérification dans votre application.
Il existe plusieurs façons courantes de vérifier les données dans Laravel, mais nous couvrirons deux des façons les plus courantes:
Pour vérifier manuellement les données (par exemple dans la méthode du contrôleur), vous pouvez utiliser la façade IlluminateSupportFacadesValidator et appeler la méthode make.
Nous pouvons ensuite transmettre deux paramètres à make Méthode:
data - Les données que nous voulons vérifier rules - Les règles que nous voulons vérifier les données basées sur Remarque latérale: La méthode make accepte également deux paramètres facultatifs: messages et attributes. Ceux-ci peuvent être utilisés pour personnaliser les messages d'erreur renvoyés à l'utilisateur, mais nous ne les couvrirons pas dans cet article.
Regardons un exemple où vous voudrez peut-être vérifier deux champs:
<input type="number" min="1" max="10" required>
Dans l'exemple ci-dessus, nous pouvons voir que nous validons deux champs: title et body. Nous avons codé en dur les valeurs de ces deux champs pour rendre l'exemple plus clair, mais dans les projets réels, vous obtenez généralement ces champs à partir de la demande. Nous vérifions si le champ title est défini, est une chaîne et a une longueur maximale de 100 caractères. Nous vérifions également si le champ description est défini, est une chaîne et a une longueur maximale de 250 caractères.
Après avoir créé le validateur, nous pouvons appeler la méthode sur l'instance renvoyée IlluminateValidationValidator. Par exemple, pour vérifier si la vérification échoue, nous pouvons appeler la méthode fails:
use Illuminate\Support\Facades\Validator;
$validator = Validator::make(
data: [
'title' => 'Blog Post',
'description' => 'Blog post description',
],
rules: [
'title' => ['required', 'string', 'max:100'],
'description' => ['required', 'string', 'max:250'],
]
); De même, nous pouvons également appeler validate Méthode sur l'instance de validateur:
$validator = Validator::make(
data: [
'title' => 'Blog Post',
'description' => 'Blog post description',
],
rules: [
'title' => ['required', 'string', 'max:100'],
'description' => ['required', 'string', 'max:250'],
]
);
if ($validator->fails()) {
// 一个或多个字段验证失败。
// 在此处进行处理...
} Si la vérification échoue, cette méthode validate augmentera IlluminateValidationValidationException. Laravel gérera automatiquement cette exception en fonction du type de demande faite (en supposant que vous n'avez pas modifié la gestion des exceptions par défaut dans votre application). Si la demande est une demande Web, Laravel utilisera des erreurs dans la session pour rediriger l'utilisateur vers la page précédente pour vous afficher. Si la demande est une demande d'API, Laravel renvoie une réponse 422 Unprocessable Entity contenant une représentation JSON de l'erreur de vérification comme suit:
Validator::make(
data: [
'title' => 'Blog Post',
'description' => 'Blog post description',
],
rules: [
'title' => ['required', 'string', 'max:100'],
'description' => ['required', 'string', 'max:250'],
]
)->validate(); Une autre façon courante de vérifier les données dans une application Laravel consiste à utiliser la classe de demande de formulaire. La classe de demande de formulaire est une classe avec une extension IlluminateFoundationHttpFormRequest qui est utilisée pour exécuter les vérifications et la validation d'autorisation sur les demandes entrantes.
Je leur trouve un excellent moyen de garder la méthode du contrôleur rangé, car Laravel exécute automatiquement la vérification sur les données réalisées dans la demande avant d'exécuter le code de la méthode du contrôleur. Par conséquent, nous n'avons pas besoin de nous rappeler d'exécuter une méthode sur l'instance validatrice nous-mêmes.
Regardons un exemple simple. Supposons que nous ayons un contrôleur de base AppHttpControllersUserController avec une méthode store qui nous permet de créer un nouvel utilisateur:
<input type="number" min="1" max="10" required>
Dans la méthode du contrôleur, nous pouvons voir que nous acceptons la classe de demande de formulaire AppHttpRequestsUsersStoreUserRequest (que nous introduirons plus tard) comme paramètres de méthode. Cela indiquera à Laravel que nous voulons exécuter automatiquement la vérification dans cette classe de demande lorsque cette méthode est appelée sur la demande HTTP.
Ensuite, nous utilisons la méthode validated sur l'instance de demande dans la méthode du contrôleur pour obtenir les données vérifiées de la demande. Cela signifie qu'il ne renverra que des données vérifiées. Par exemple, si nous essayons d'enregistrer un nouveau champ profile_picture dans le contrôleur, nous devons également l'ajouter à la classe de demande de formulaire. Sinon, la méthode validated ne le retournera pas, donc $request->validated('profile_picture') renvoie null.
Jetons un coup d'œil à AppHttpRequestsUsersStoreUserRequest Classe de demande de formulaire:
use Illuminate\Support\Facades\Validator;
$validator = Validator::make(
data: [
'title' => 'Blog Post',
'description' => 'Blog post description',
],
rules: [
'title' => ['required', 'string', 'max:100'],
'description' => ['required', 'string', 'max:250'],
]
);Nous pouvons voir que la classe de demande contient deux méthodes:
authorize: Cette méthode est utilisée pour déterminer si l'utilisateur a le droit de faire une demande. Si la méthode renvoie false, une réponse 403 Forbidden est renvoyée à l'utilisateur. Si la méthode renvoie true, la règle de vérification sera exécutée. rules: Cette méthode est utilisée pour définir les règles de validation qui doivent être exécutées sur la demande. Cette méthode doit renvoyer un tableau de règles qui doivent être exécutées sur la demande. Dans la méthode rules, nous spécifions que le champ name doit être défini, doit être une chaîne et que la longueur maximale doit être de 100 caractères. Nous spécifions également que le champ email doit être défini, doit être un e-mail et doit être unique dans le tableau users (sur la colonne email). Enfin, nous spécifions que le champ password doit être défini et doit passer les règles de vérification de mot de passe par défaut que nous avons définies (nous couvrirons la vérification du mot de passe plus tard).
Comme vous pouvez le voir, c'est un excellent moyen de séparer la logique de vérification de la logique du contrôleur, et j'ai trouvé que cela rend le code plus facile à lire et à maintenir.
Comme je l'ai déjà mentionné, le système de vérification Laravel est très puissant et peut facilement ajouter une vérification à votre application.
Dans cette section, nous présenterons rapidement des règles de vérification pratiques que j'aime, ce que je pense que la plupart des utilisateurs trouveront utiles dans leurs applications.
Si vous souhaitez consulter toutes les règles disponibles dans Laravel, vous pouvez les trouver dans la documentation Laravel:https://www.php.cn/link/45d5c43856059a4f97d43d6534be52d0
# Vérifiez le tableauRegardons un exemple de la façon de valider un tableau, puis nous discuterons de ce qui est effectué:
<input type="number" min="1" max="10" required>
Dans l'exemple ci-dessus, nous passons un tableau d'objets, chacun avec des champs name et email.
Pour la vérification, nous définissons d'abord que le champ users est défini et est un tableau. Ensuite, nous spécifions que chaque élément du tableau (en utilisant users.* direction) est un tableau contenant les champs name et email.
Ensuite, nous spécifions que le champ name (Utilisation de la direction users.*.name) doit être défini, doit être une chaîne et ne peut pas dépasser 100 caractères. Nous spécifions également que le champ email (utilisant users.*.email Directions) doit être défini, doit être un e-mail et doit être unique sur la colonne users du tableau email.
En étant en mesure d'utiliser le wildcard * dans les règles de vérification, nous pouvons facilement vérifier le tableau de données dans notre application.
Laravel fournit quelques règles de vérification de date pratiques que vous pouvez utiliser. Tout d'abord, pour vérifier qu'un champ est une date valide, vous pouvez utiliser la règle date:
use Illuminate\Support\Facades\Validator;
$validator = Validator::make(
data: [
'title' => 'Blog Post',
'description' => 'Blog post description',
],
rules: [
'title' => ['required', 'string', 'max:100'],
'description' => ['required', 'string', 'max:250'],
]
); Si vous préférez vérifier si une date est dans un format spécifique, vous pouvez utiliser date_format Règles:
$validator = Validator::make(
data: [
'title' => 'Blog Post',
'description' => 'Blog post description',
],
rules: [
'title' => ['required', 'string', 'max:100'],
'description' => ['required', 'string', 'max:250'],
]
);
if ($validator->fails()) {
// 一个或多个字段验证失败。
// 在此处进行处理...
} Vous devrez peut-être vérifier si la date est antérieure ou plus tard qu'une autre date. Par exemple, supposons que votre demande contient les champs opens_at et closes_at, et que vous souhaitez vous assurer que closes_at est plus tard que opens_at et opens_at est plus tard ou égal à aujourd'hui. Vous pouvez utiliser after Règles:
Validator::make(
data: [
'title' => 'Blog Post',
'description' => 'Blog post description',
],
rules: [
'title' => ['required', 'string', 'max:100'],
'description' => ['required', 'string', 'max:250'],
]
)->validate(); Dans l'exemple ci-dessus, nous pouvons voir que nous avons passé today comme paramètre à la règle opens_at du champ after. Laravel essaiera de convertir cette chaîne en un objet strtotime valide à l'aide de la fonction DateTime et de le comparer à cet objet.
Pour le champ closes_at, nous passons opens_at en tant que paramètre à la règle after_or_equal. Laravel détectera automatiquement qu'il s'agit d'un autre champ validé et comparera les deux champs les uns aux autres.
De même, Laravel fournit également des règles before et before_or_equal que vous pouvez utiliser pour vérifier si une date est antérieure à une autre date:
{
"message": "The title field is required. (and 1 more error)",
"errors": {
"title": [
"The title field is required."
],
"description": [
"The description field is required."
]
}
}En tant que développeurs Web, notre travail consiste à aider les utilisateurs en sécurité en ligne. Une façon dont nous pouvons le faire est de promouvoir de bonnes pratiques de mot de passe dans nos applications, comme l'exiger des mots de passe comme une certaine longueur, contiennent certains caractères, etc.
Laravel simplifie notre travail en fournissant une classe IlluminateValidationRulesPassword que nous pouvons utiliser pour vérifier les mots de passe.
Il est livré avec certaines méthodes que nous pouvons lier ensemble pour créer les règles de vérification du mot de passe que nous voulons. Par exemple, supposons que nous voulions que le mot de passe de l'utilisateur réponde aux critères suivants:
Notre vérification peut ressembler à ceci:
<input type="number" min="1" max="10" required>
Comme le montre l'exemple, nous utilisons une méthode lienable pour créer les règles de vérification du mot de passe que nous voulons. Mais que se passe-t-il si nous utilisons ces règles à plusieurs endroits différents (par exemple, inscrivez-vous, réinitialisez le mot de passe, mise à jour du mot de passe sur la page de votre compte, etc.) et que nous devons modifier cette vérification pour appliquer au moins 12 caractères? Nous devons parcourir tout ce que ces règles sont utilisées et les mettre à jour.
Pour simplifier cela, Laravel nous permet de définir un ensemble par défaut de règles de vérification de mot de passe que nous pouvons utiliser tout au long de notre application. Nous pouvons définir un ensemble de règles par défaut en utilisant la méthode AppProvidersAppServiceProvider comme celle-ci dans notre méthode boot: Password::defaults()
use Illuminate\Support\Facades\Validator;
$validator = Validator::make(
data: [
'title' => 'Blog Post',
'description' => 'Blog post description',
],
rules: [
'title' => ['required', 'string', 'max:100'],
'description' => ['required', 'string', 'max:250'],
]
); dans la règle de validation et utiliser les règles que nous avons spécifiées dans Password::defaults() pour: AppServiceProvider
$validator = Validator::make(
data: [
'title' => 'Blog Post',
'description' => 'Blog post description',
],
rules: [
'title' => ['required', 'string', 'max:100'],
'description' => ['required', 'string', 'max:250'],
]
);
if ($validator->fails()) {
// 一个或多个字段验证失败。
// 在此处进行处理...
}Dans le passé, j'ai dû utiliser des expressions régulières (j'avoue que je n'en sais pas grand-chose) pour vérifier que la couleur est une couleur valide au format hexadécimal (par exemple
). Cependant, Laravel a maintenant un #FF00FF pratique à utiliser: hex_color
Validator::make(
data: [
'title' => 'Blog Post',
'description' => 'Blog post description',
],
rules: [
'title' => ['required', 'string', 'max:100'],
'description' => ['required', 'string', 'max:250'],
]
)->validate();Supposons que vous souhaitiez permettre aux utilisateurs de télécharger des fichiers PDF (.pdf) ou Microsoft Word (.Docx). La vérification peut ressembler à ceci:
{
"message": "The title field is required. (and 1 more error)",
"errors": {
"title": [
"The title field is required."
],
"description": [
"The description field is required."
]
}
} pour spécifier le type de fichier que nous souhaitons autoriser. types
Les méthodes
et min peuvent également accepter des chaînes contenant d'autres suffixes qui indiquent des unités de taille de fichier. Par exemple, nous pouvons également utiliser: max
10kb
10mb
10gb
10tb
sur la classe IlluminateValidationRulesFile pour nous assurer que le fichier est une image: image
<input type="number" min="1" max="10" required>
Dans l'exemple ci-dessus, nous vérifions que le fichier est une image, définit des limites de taille de fichier minimum et maximale et définit des tailles maximales (500 x 500 pixels).
Vous voudrez peut-être adopter une approche différente pour les téléchargements de fichiers dans votre application. Par exemple, vous souhaiterez peut-être télécharger directement du navigateur de l'utilisateur vers le stockage cloud (par exemple S3). Si vous préférez le faire, vous souhaiterez peut-être consulter mes fichiers de téléchargement dans l'article de Laravel à l'aide de FilePond, qui vous montre comment procéder, les différentes méthodes de vérification que vous pourriez avoir besoin de prendre et comment la tester.
Une autre vérification courante que vous voudrez peut-être faire est de s'assurer qu'une valeur existe dans la base de données.
Par exemple, supposons que vous ayez des utilisateurs dans votre application et que vous avez créé un itinéraire afin que vous puissiez les attribuer par lots aux équipes. Par conséquent, dans votre demande, vous devrez peut-être vérifier que le user_ids adopté dans la demande existe dans le tableau users.
Pour ce faire, vous pouvez utiliser la règle exists et passer le nom de la table que vous souhaitez vérifier si la valeur existe:
use Illuminate\Support\Facades\Validator;
$validator = Validator::make(
data: [
'title' => 'Blog Post',
'description' => 'Blog post description',
],
rules: [
'title' => ['required', 'string', 'max:100'],
'description' => ['required', 'string', 'max:250'],
]
); Dans l'exemple ci-dessus, nous vérifions si chaque ID passé dans le tableau user_ids existe dans la colonne users du tableau id.
C'est un excellent moyen de s'assurer que les données que vous utilisez sont valides et existent dans la base de données avant d'essayer de les utiliser.
Si vous souhaitez aller plus loin, vous pouvez appliquer la clause where à la règle exists pour filtrer davantage les requêtes en cours:
$validator = Validator::make(
data: [
'title' => 'Blog Post',
'description' => 'Blog post description',
],
rules: [
'title' => ['required', 'string', 'max:100'],
'description' => ['required', 'string', 'max:250'],
]
);
if ($validator->fails()) {
// 一个或多个字段验证失败。
// 在此处进行处理...
} Dans l'exemple ci-dessus, nous vérifions si chaque ID passé dans le tableau user_ids existe dans la colonne users de la table id, et la colonne is_verified de l'utilisateur est définie sur true. Par conséquent, si nous passons un ID utilisateur non vérifié, la vérification échouera.
Similaire à la règle exists, Laravel fournit également une règle unique que vous pouvez utiliser pour vérifier si les valeurs de la base de données sont uniques.
Par exemple, supposons que vous ayez une table users et que vous souhaitez vous assurer que le champ email est unique. Vous pouvez utiliser unique Règles:
Validator::make(
data: [
'title' => 'Blog Post',
'description' => 'Blog post description',
],
rules: [
'title' => ['required', 'string', 'max:100'],
'description' => ['required', 'string', 'max:250'],
]
)->validate(); Dans l'exemple ci-dessus, nous vérifions si le champ email est défini, est un e-mail et est unique sur la colonne users du tableau email.
Cependant, que se passe-t-il si nous essayons d'utiliser cette vérification sur une page de profil où l'utilisateur peut mettre à jour son adresse e-mail? La vérification échouera car il y a une ligne dans le tableau users contenant l'adresse e-mail à laquelle l'utilisateur a tenté de mettre à jour. Dans ce cas, nous pouvons utiliser la méthode ignore pour ignorer l'ID utilisateur lors de la vérification de l'unicité:
{
"message": "The title field is required. (and 1 more error)",
"errors": {
"title": [
"The title field is required."
],
"description": [
"The description field is required."
]
}
} Si vous choisissez d'utiliser la méthode ignore, vous devez être sûr de lire cet avertissement dans la documentation de Laravel:
"Vous ne devez jamais transmettre aucune entrée de demande contrôlée par l'utilisateur dans la méthode ignore. Au lieu de cela, vous ne devez passer qu'un ID unique généré par le système, tel qu'un ID d'auto-incitation ou UUID à partir d'une instance de modèle éloquente. Sinon, votre application sera vulnérable aux attaques d'injection SQL."
Il se peut aussi que vous souhaitez parfois ajouter des clauses unique supplémentaires à la règle where. Vous devrez peut-être le faire pour vous assurer que l'adresse e-mail est unique à une équipe spécifique (ce qui signifie qu'un autre utilisateur d'une autre équipe peut utiliser le même e-mail). Vous pouvez le faire en passant la fermeture à la méthode where:
<input type="number" min="1" max="10" required>
Bien que Laravel soit livré avec de nombreuses règles de validation intégrées, vous devrez peut-être créer des règles de validation personnalisées en fonction des cas d'utilisation spécifiques.
Dieu merci, c'est aussi facile à faire à Laravel!
Voyons comment créer des règles de validation personnalisées, comment l'utiliser, puis comment rédiger des tests pour cela.
Aux fins de cet article, nous ne sommes pas très préoccupés par ce que nous vérifions. Nous voulons simplement comprendre la structure générale de la création de règles de validation personnalisées et comment les tester. Par conséquent, nous créerons une règle simple pour vérifier si la chaîne est palindrome.
Si vous ne le savez pas, un palindrome est une séquence de mots, de phrases, de nombres ou d'autres caractères qui lisent la même chose dans les directions avant et inverse. Par exemple, "Racecar" est un palindrome parce que si vous inversez la chaîne, c'est toujours "la voiture de course". Et "Laravel" n'est pas un palindrome, car si vous inversez la chaîne, ce sera "levaral".
Pour commencer, nous allons d'abord créer une nouvelle règle de validation en exécutant la commande suivante dans la route du projet:
use Illuminate\Support\Facades\Validator;
$validator = Validator::make(
data: [
'title' => 'Blog Post',
'description' => 'Blog post description',
],
rules: [
'title' => ['required', 'string', 'max:100'],
'description' => ['required', 'string', 'max:250'],
]
); Cela devrait créer un nouveau fichier App/Rules/Palindrome.php pour nous:
$validator = Validator::make(
data: [
'title' => 'Blog Post',
'description' => 'Blog post description',
],
rules: [
'title' => ['required', 'string', 'max:100'],
'description' => ['required', 'string', 'max:250'],
]
);
if ($validator->fails()) {
// 一个或多个字段验证失败。
// 在此处进行处理...
} Laravel appellera automatiquement la méthode validate lors de l'exécution de la règle. Cette méthode accepte trois paramètres:
$attribute: Le nom de la propriété est vérifié. $value: La valeur de la propriété est vérifiée. $fail: La fermeture que vous pouvez appeler en cas d'échec de la vérification. Par conséquent, nous pouvons ajouter notre logique de vérification à la méthode validate comme suit:
Validator::make(
data: [
'title' => 'Blog Post',
'description' => 'Blog post description',
],
rules: [
'title' => ['required', 'string', 'max:100'],
'description' => ['required', 'string', 'max:250'],
]
)->validate(); Dans la règle ci-dessus, nous vérifions simplement si la valeur transmise à la règle est la même que la valeur qu'il inverse. Sinon, nous appellerons la fermeture $fail avec le message d'erreur. Cela entraînera la vérification du champ. Si la vérification passe, la règle n'effectuera rien et nous pouvons continuer à utiliser notre application.
Maintenant que nous avons créé la règle, nous pouvons l'utiliser dans notre application comme ceci:
{
"message": "The title field is required. (and 1 more error)",
"errors": {
"title": [
"The title field is required."
],
"description": [
"The description field is required."
]
}
}Bien qu'il s'agisse d'une règle simple que nous avons créée à des fins de démonstration, j'espère que cela vous donnera une idée de la façon de créer des règles plus complexes pour votre application.
Comme tout autre code de votre application, il est important de tester vos règles de validation pour vous assurer qu'ils fonctionnent comme prévu. Sinon, vous pouvez risquer d'utiliser des règles qui ne fonctionnent pas comme prévu.
Pour comprendre comment procéder, jetons un coup d'œil à tester les règles de Palindrome que nous avons créées dans la section précédente.
Pour cette règle spécifique, nous voulons tester deux situations:
Vous pouvez avoir plus de situations dans des règles plus complexes, mais aux fins de cet article, nous restons simples.
Nous créerons un nouveau fichier de test nommé tests/Unit/Rules dans le répertoire PalindromeTest.php.
Jetons un coup d'œil au fichier de test, puis nous discuterons de ce qui est effectué:
<input type="number" min="1" max="10" required>
Dans le fichier de test ci-dessus, nous définissons deux tests: rule_passes_with_a_valid_value et rule_fails_with_an_invalid_value.
Comme l'indique le nom du test, le premier test garantit que la règle passe lorsque la valeur est palindrome, et le deuxième test garantit que la règle échoue lorsque la valeur n'est pas palindrome.
Nous utilisons l'attribut PHPUnitFrameworkAttributesDataProvider pour fournir une liste de valeurs valides et non valides pour le test de test. C'est un excellent moyen de garder vos tests soignés et de pouvoir vérifier plusieurs valeurs avec le même test. Par exemple, si quelqu'un ajoute une nouvelle valeur valide à la méthode validValues, le test s'exécutera automatiquement contre cette valeur.
Dans le test rule_passes_with_a_valid_value, nous utilisons des valeurs valides pour appeler la méthode validate sur la règle. Nous passons la fermeture au paramètre fail (ce paramètre est appelé si la validation interne de la règle échoue). Nous avons spécifié que si la fermeture est exécutée (c'est-à-dire que la vérification a échoué), le test devrait échouer. Si nous atteignons la fin du test sans exécuter la fermeture, nous savons que la règle s'est écoulée et que nous pouvons ajouter une affirmation simple assertTrue(true) pour réussir le test.
Dans le test rule_fails_with_an_invalid_value, nous sommes les mêmes que les premiers, mais cette fois, nous passons la valeur non valide à la règle. Nous avons spécifié que si la fermeture est exécutée (c'est-à-dire que la vérification a échoué), le test devrait passer parce que nous nous attendons à ce que la fermeture soit appelée. Si nous atteignons la fin du test sans exécuter la fermeture, aucune affirmation n'est exécutée et PHPUnit devrait déclencher un avertissement pour nous. Cependant, si vous préférez vous assurer que le test échoue plus explicitement que de simplement donner des erreurs, vous devrez peut-être adopter une approche légèrement différente pour rédiger le test.
Dans cet article, nous examinons quelle est la vérification et pourquoi elle est importante. Nous avons comparé la vérification côté client avec la vérification côté serveur et exploré pourquoi la vérification côté client ne devrait pas être utilisée comme seule forme de vérification dans l'application.
Nous avons également couvert quelques règles de vérification pratiques que j'aime utiliser dans mon application Laravel. Enfin, nous explorons comment créer vos propres règles de validation et les tester pour nous assurer qu'ils fonctionnent comme prévu.
J'espère que vous devriez maintenant être suffisamment confiant pour commencer à utiliser plus de vérification pour améliorer la sécurité et la fiabilité de votre application.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
attributusage
Solution au succès de Java et à l'échec de Javac
Comment définir le retour à la ligne automatique dans Word
introduction à la commande route add
Nettoyer le registre
Que faire si une erreur normal.dotm se produit
Algorithme du complément négatif
Comment basculer entre les systèmes doubles Huawei
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
