Datenüberprüfung ist eine Schlüsselkomponente jeder Webanwendung. Es hilft, Sicherheitslücken, Datenbeschäftigung und verschiedene andere Probleme zu verhindern, die bei der Verwendung von Benutzereingaben möglicherweise auftreten können.
In diesem Artikel wird untersucht, was die Datenüberprüfung ist und warum er so wichtig ist. Wir werden die clientseitige Überprüfung mit der serverseitigen Überprüfung vergleichen und erklären, warum die clientseitige Überprüfung nicht aufgenommen werden sollte.
Wir werden dann einige bequeme Überprüfungsregeln einführen, die ich häufig in meiner Laravel -Anwendung verwende. Schließlich lernen wir, wie wir unsere eigenen Validierungsregeln erstellen und sie testen, um sicherzustellen, dass sie wie erwartet funktionieren.
Datenüberprüfung ist ein Prozess der Überprüfung der Gültigkeit von Daten, bevor Sie versuchen, sie zu verwenden. Dies kann ein einfaches Element sein, das Sie überprüfen können, um beispielsweise unabhängig davon, ob die erforderlichen Felder in der Anforderung vorhanden sind, oder komplexere Überprüfungen, z. B. ob die Felder mit einem bestimmten Muster übereinstimmen oder ob sie in der Datenbank eindeutig sind.
Normalerweise müssen Sie beim Überprüfen von Daten in einer Webanwendung, wenn die Daten ungültig sind, eine Fehlermeldung an den Benutzer zurückgeben.
Dies hilft, Sicherheitsanfälligkeiten, Datenversorgung zu verhindern und die Datengenauigkeit zu verbessern. Daher werden wir die Anfrage weiterhin nur dann bearbeiten, wenn die Daten gültig sind.
Denken Sie daran, Sie können keine Daten des Benutzers vertrauen (zumindest bevor Sie sie überprüfen!).
Es gibt viele Gründe, warum die Datenüberprüfung wichtig ist, einschließlich:
Einer der wichtigsten Gründe, um Daten in Ihrer Anwendung zu überprüfen, ist die Verbesserung der Sicherheit. Durch die Überprüfung der Daten vor der Verwendung können Sie die Möglichkeit verringern, dass böswillige Eingaben verwendet werden, um Ihre App oder Benutzer anzugreifen.
Stellen Sie sich vor, wir erwarten, dass ein Feld eine Ganzzahl ist, aber der Benutzer übergibt eine Datei. Dies kann zu verschiedenen Problemen führen, wenn wir versuchen, diese Daten an anderer Stelle in der App zu verwenden.
Um ein weiteres Beispiel zu geben, nehmen Sie an, Sie erstellen eine Webanwendung, mit der Benutzer über die Abstimmung abstimmen können. Die Abstimmung kann nur zwischen AppModelsPoll Zeit und opens_at -Time, die auf dem closes_at -Modell angegeben ist, abgestimmt werden. Was passiert, wenn jemand versehentlich die closes_at Zeit vor der opens_at -Präutung bei der Einrichtung einer Abstimmung festlegt? Abhängig davon, wie Sie damit in Ihrer App umgehen, kann dies zu verschiedenen Problemen führen.
Durch Validieren von Daten vor dem Speichern des Modells können wir die Datengenauigkeit in unserer Anwendung verbessern und die Möglichkeit reduzieren, dass falsche Daten gespeichert werden.
Zusätzlich zur Überprüfung der in HTTP -Anfragen übergebenen Daten können Sie auch den Handwerksbefehl überprüfen. Dies verhindert, dass Entwickler versehentlich ungültige Werte eingeben und Probleme mit der Anwendung verursachen.
Normalerweise können Sie zwei Arten der Überprüfung in Ihrer Anwendung verwenden: clientseitige Überprüfung und serverseitige Überprüfung.
Zum Beispiel können wir dem Feld der Zahl in HTML eine einfache Validierung hinzufügen, um sicherzustellen, dass die vom Benutzer eingegebene Nummer zwischen 1 und 10 liegt:
<input type="number" min="1" max="10" required>
type="number"
min="1"
max="10"
required
Dies ist sehr vorteilhaft, um Benutzer zu führen und die allgemeine Benutzererfahrung der Anwendung zu verbessern. Aber das sollte nur berücksichtigt werden: ein Leitfaden. Sie sollten sich nicht nur auf die Client -Authentifizierung als die einzige Form der Überprüfung in Ihrer Anwendung verlassen.
Wenn jemand die Entwicklerwerkzeuge in seinem Browser öffnet, können er die von Ihnen festgelegte Clientüberprüfung problemlos entfernen und umgehen.
Darüber hinaus ist es wichtig zu beachten, dass böswillige Benutzer, wenn sie versuchen, Ihre App anzugreifen, normalerweise automatisierte Skripte verwendet, um Anforderungen direkt an Ihren Server zu senden. Dies bedeutet, dass die von Ihnen festgelegte Clientüberprüfung umgangen wird.
# serverseitige Überprüfung
Da sich die Überprüfung auf Ihrem Server befindet, kann der Benutzer dies nicht ändern. Dies ist der einzige Weg, um wirklich sicherzustellen, dass die an den Server gesendeten Daten gültig sind.
Aktivieren Sie daher unbedingt die serverseitige Überprüfung in Ihrer App. Im Idealfall sollte jedes Feld, das Sie aus der Anfrage lesen möchten, überprüft werden, bevor Sie versuchen, es zu verwenden, um eine Geschäftslogik auszuführen.
Wie Laravel verifiziert
Wenn Sie Laravel schon eine Weile verwendet haben, wissen Sie, dass Laravel ein erstaunliches Überprüfungssystem in das Rahmen integriert hat. Daher ist es sehr einfach, mit der Überprüfung in Ihrer App zu beginnen.
Es gibt mehrere häufige Möglichkeiten, um Daten in Laravel zu überprüfen, aber wir werden zwei der häufigsten Möglichkeiten abdecken:
Um die Daten manuell zu überprüfen (z. B. in der Controller -Methode), können Sie die Fassade IlluminateSupportFacadesValidator verwenden und die make -Methode aufrufen.
Wir können dann zwei Parameter an make Methode übergeben:
data - Die Daten, die wir rules - Die Regeln, die wir Daten basierend auf Seitennotiz: Die make -Methode akzeptiert auch zwei optionale Parameter: messages und attributes. Diese können verwendet werden, um Fehlermeldungen anzupassen, die an den Benutzer zurückgegeben wurden, aber wir werden sie in diesem Artikel nicht behandeln.
Schauen wir uns ein Beispiel an, in dem Sie vielleicht zwei Felder überprüfen möchten:
<input type="number" min="1" max="10" required>
Im obigen Beispiel können wir sehen, dass wir zwei Felder validieren: title und body. Wir haben die Werte dieser beiden Felder fest codiert, um das Beispiel klarer zu machen, aber in realen Projekten erhalten Sie normalerweise diese Felder aus der Anfrage. Wir prüfen, ob das Feld title eingestellt ist, eine Zeichenfolge ist und eine maximale Länge von 100 Zeichen hat. Wir prüfen auch, ob das Feld description eingestellt ist, eine Zeichenfolge ist und eine maximale Länge von 250 Zeichen hat.
Nach dem Erstellen des Validators können wir die Methode auf der zurückgegebenen IlluminateValidationValidator -Schelle aufrufen. Um beispielsweise zu überprüfen, ob die Überprüfung fehlschlägt, können wir die Methode fails aufrufen:
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'],
]
); In ähnlicher Weise können wir auch die Methode auf der Validator -Instanz aufrufen: validate
$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()) {
// 一个或多个字段验证失败。
// 在此处进行处理...
} -Methode validate. Laravel wird diese Ausnahme automatisch basierend auf der Art der gestellten Anforderung behandeln (vorausgesetzt, Sie haben die Standardausnahmebehandlung in Ihrer App nicht geändert). Wenn es sich bei der Anfrage um eine Webanforderung handelt, verwendet Laravel Fehler in der Sitzung, um den Benutzer wieder zur vorherigen Seite zu leiten, damit Sie angezeigt werden können. Wenn die Anforderung eine API -Anforderung ist, gibt Laravel eine IlluminateValidationValidationException Antwort zurück, die eine JSON -Darstellung des Überprüfungsfehlers wie folgt enthält: 422 Unprocessable Entity
Validator::make(
data: [
'title' => 'Blog Post',
'description' => 'Blog post description',
],
rules: [
'title' => ['required', 'string', 'max:100'],
'description' => ['required', 'string', 'max:250'],
]
)->validate();, mit der Autorisierungsüberprüfungen und Validierung bei eingehenden Anforderungen durchgeführt werden. IlluminateFoundationHttpFormRequest
Schauen wir uns ein einfaches Beispiel an. Angenommen, wir haben einen grundlegenden
Controller mit einer AppHttpControllersUserController -Methode, mit der wir einen neuen Benutzer erstellen können: store
<input type="number" min="1" max="10" required>
In der Controller -Methode können wir sehen, dass wir die AppHttpRequestsUsersStoreUserRequest Formularanforderungsklasse (die wir später einführen werden) als Methodenparameter akzeptieren. Dies zeigt Laravel, dass wir die Überprüfung in dieser Anforderungsklasse automatisch ausführen möchten, wenn diese Methode über die HTTP -Anforderung gerufen wird.
Dann verwenden wir die validated -Methode in der Anforderungsinstanz in der Controller -Methode, um die verifizierten Daten aus der Anforderung abzurufen. Dies bedeutet, dass nur verifizierte Daten zurückgegeben werden. Wenn wir beispielsweise versuchen, ein neues profile_picture -Feld im Controller zu speichern, müssen wir es auch der Formularanforderungsklasse hinzufügen. Andernfalls gibt die validated -Methode es nicht zurück, sodass $request->validated('profile_picture') null zurückgibt.
Schauen wir uns AppHttpRequestsUsersStoreUserRequest Formularanforderungsklasse an:
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'],
]
);Wir können sehen, dass die Anforderungsklasse zwei Methoden enthält:
authorize: Diese Methode wird verwendet, um festzustellen, ob der Benutzer das Recht hat, eine Anfrage zu stellen. Wenn die Methode false zurückgibt, wird eine 403 Forbidden Antwort an den Benutzer zurückgegeben. Wenn die Methode true zurückgibt, wird die Überprüfungsregel ausgeführt. rules: Diese Methode wird verwendet, um die Validierungsregeln zu definieren, die auf der Anforderung ausgeführt werden sollten. Diese Methode sollte eine Reihe von Regeln zurückgeben, die auf der Anfrage ausgeführt werden sollten. In der Methode rules geben wir an, dass das Feld name festgelegt werden muss, eine Zeichenfolge sein muss und die maximale Länge 100 Zeichen betragen muss. Wir geben auch an, dass das Feld email festgelegt werden muss, eine E -Mail sein muss und in der Tabelle users eindeutig sein muss (in der Spalte email). Schließlich geben wir an, dass das Feld password festgelegt werden muss und die von uns festgelegten Standard -Kennwortüberprüfungsregeln übergeben werden muss (wir werden später die Passwortüberprüfung abdecken).
Wie Sie sehen, ist dies eine großartige Möglichkeit, die Überprüfungslogik von der Controller -Logik zu trennen, und ich fand, dass der Code leichter zu lesen und zu warten ist.
Wie ich bereits erwähnt habe, ist das Laravel -Verifizierungssystem sehr leistungsfähig und kann Ihrer App problemlos Überprüfung hinzufügen.
In diesem Abschnitt werden wir schnell einige bequeme Überprüfungsregeln einführen, die mir gefallen, die meiner Meinung nach die meisten Benutzer in ihren Apps nützlich finden.
Wenn Sie alle in Laravel verfügbaren Regeln anzeigen möchten, finden Sie sie in der Laravel -Dokumentation: https://www.php.cn/link/45d5c43856059a4f97d43d6534be52d0
# prüfen Sie Array
Eine gemeinsame Validierungsart, die Sie ausführen müssen, ist das Validierungsarray. Dies kann von der Überprüfung erfolgen, ob das bestandene ID -Array alle gültig ist, um zu überprüfen, ob das in der Verifizierungsanforderung bestehende Objektarray bestimmte Felder enthält. Schauen wir uns ein Beispiel dafür an, wie ein Array validiert werden kann, und dann werden wir diskutieren, was ausgeführt wird:
<input type="number" min="1" max="10" required>
In dem obigen Beispiel übergeben wir ein Array von Objekten, jeweils ein name und email Felder.
Zur Überprüfung definieren wir zunächst, dass das Feld users ein Array ist. Anschließend geben wir an, dass jedes Element des Arrays (unter Verwendung users.* Richtung) ein Array ist, das die Felder name und email enthält.
Dann geben wir an, dass das Feld name (mit users.*.name Richtung) eingestellt sein muss, eine Zeichenfolge sein muss und nicht 100 Zeichen überschreiten darf. Wir geben auch an, dass das Feld email (mit users.*.email Anweisungen) festgelegt werden muss, eine E -Mail sein muss und in der Spalte users eindeutig sein muss. email
Wildcard verwenden können, können wir das Datenarray in unserer Anwendung problemlos überprüfen. *
Regel: date verwenden
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'],
]
); Regeln verwenden: date_format
$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()) {
// 一个或多个字段验证失败。
// 在此处进行处理...
} und opens_at, und Sie möchten sicherstellen, dass closes_at später als closes_at und opens_at später als heute oder gleich ist. Sie können opens_at Regeln verwenden: after
Validator::make(
data: [
'title' => 'Blog Post',
'description' => 'Blog post description',
],
rules: [
'title' => ['required', 'string', 'max:100'],
'description' => ['required', 'string', 'max:250'],
]
)->validate(); als Parameter an die today -Regel des Feldes opens_at übergeben haben. Laravel versucht, diese Zeichenfolge unter Verwendung der after -Funktion in ein gültiges strtotime -Objekt umzuwandeln und mit diesem Objekt zu vergleichen. DateTime
übergeben wir closes_at als Parameter an die opens_at -Regel. Laravel erkennt automatisch, dass dies ein anderes Feld ist, das validiert wird, und vergleichen die beiden Felder miteinander. after_or_equal
und before Regeln, mit denen Sie überprüfen können, ob ein Datum früher als ein weiteres Datum ist: before_or_equal
{
"message": "The title field is required. (and 1 more error)",
"errors": {
"title": [
"The title field is required."
],
"description": [
"The description field is required."
]
}
}laravel vereinfacht unsere Arbeit, indem wir eine
-Klasse bereitstellen, mit der wir Passwörter überprüfen können. IlluminateValidationRulesPassword
Unsere Überprüfung kann so aussehen:
<input type="number" min="1" max="10" required>
Wie im Beispiel gezeigt, verwenden wir eine verknüpfbare Methode, um die gewünschten Kennwortüberprüfungsregeln zu erstellen. Aber was passiert, wenn wir diese Regeln an mehreren verschiedenen Orten verwenden (z. B. Registrieren, Kennwort zurücksetzen, das Passwort auf Ihrer Kontoseite usw. aktualisieren) und wir müssen diese Überprüfung ändern, um mindestens 12 Zeichen durchzusetzen? Wir müssen alles durch alles iterieren, wo diese Regeln verwendet werden, und sie aktualisieren.
AppProvidersAppServiceProvider Um dies zu vereinfachen, ermöglicht es uns Laravel, einen Standardsatz von Kennwortüberprüfungsregeln zu definieren, die wir in unserer Anwendung verwenden können. Wir können eine Reihe von Standardregeln definieren, indem wir die Methode boot in unserer Password::defaults() -Methode verwenden:
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'],
]
); Danach können wir jetzt in der Validierungsregel Password::defaults() aufrufen und die in AppServiceProvider angegebenen Regeln für:
$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()) {
// 一个或多个字段验证失败。
// 在此处进行处理...
}Fast jedes Projekt, an dem ich gearbeitet habe, enthält eine Form von Farbwähler. Unabhängig davon, ob es sich um einen Benutzer handelt, der eine Farbe für sein Profil, eine Hintergrundfarbe für einen Teil der Seite oder einen anderen Inhalt auswählt, handelt es sich um einen gemeinsamen Inhalt.
In der Vergangenheit musste ich regelmäßige Ausdrücke verwenden (ich gebe zu, ich weiß nicht viel darüber), um zu überprüfen, ob die Farbe eine gültige Farbe im Hex -Format ist (z. B. #FF00FF). Laravel hat jetzt jedoch eine bequeme hex_color zu verwenden:
Validator::make(
data: [
'title' => 'Blog Post',
'description' => 'Blog post description',
],
rules: [
'title' => ['required', 'string', 'max:100'],
'description' => ['required', 'string', 'max:250'],
]
)->validate();Wenn Sie Dateien über den Server in die App hochladen, müssen Sie überprüfen, ob die Dateien gültig sind, bevor Sie versuchen, sie zu speichern. Wie Sie sich vorstellen können, enthält Laravel einige Dateiüberprüfungsregeln, die Sie verwenden können.
Angenommen, Sie möchten Benutzern ermöglichen, PDF (.pDF) oder Microsoft Word (.docx) -Dateien hochzuladen. Die Überprüfung kann so aussehen:
{
"message": "The title field is required. (and 1 more error)",
"errors": {
"title": [
"The title field is required."
],
"description": [
"The description field is required."
]
}
} Im Codebeispiel können wir feststellen, dass wir den Dateityp überprüfen und auch einige minimale und maximale Dateigrößengrenzen festlegen. Wir verwenden die types -Methode, um den Dateityp anzugeben, den wir zulassen möchten.
min und max können auch Zeichenfolgen akzeptieren, die andere Suffixe enthalten, die Einheiten der Dateigröße angeben. Zum Beispiel können wir auch verwenden:
10kb 10mb 10gb 10tb Zusätzlich können wir auch die IlluminateValidationRulesFile -Methode in der image -Klasse verwenden, um sicherzustellen, dass die Datei ein Bild ist:
<input type="number" min="1" max="10" required>
Im obigen Beispiel überprüfen wir, dass es sich bei der Datei um ein Bild handelt. Setzen Sie einige minimale und maximale Dateigrößengrenzen und setzen einige maximale Größen (500 x 500 Pixel) ein.
Möglicherweise möchten Sie einen anderen Ansatz für Datei -Uploads in Ihrer App verfolgen. Zum Beispiel möchten Sie möglicherweise direkt vom Browser des Benutzers auf Cloud -Speicher hochladen (z. B. S3). Wenn Sie dies vorziehen, möchten Sie meine Upload -Dateien in Laravel -Artikel mit FilePond überprüfen, die Ihnen zeigen, wie dies zu tun ist, die verschiedenen Überprüfungsmethoden, die Sie möglicherweise einnehmen müssen, und wie Sie es testen.
Eine weitere gemeinsame Prüfung, die Sie möglicherweise durchführen möchten, ist, dass in der Datenbank ein Wert vorhanden ist.
Angenommen, Sie haben einige Benutzer in Ihrer App und haben eine Route erstellt, damit Sie sie den Teams zuweisen können. In Ihrer Anfrage müssen Sie daher möglicherweise überprüfen, ob der in der Anfrage übergebene user_ids in der Tabelle users vorhanden ist.
, um dies zu tun.
exists
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'],
]
); in der Tabelle user_ids vorhanden ist. users
id Dies ist eine großartige Möglichkeit, um sicherzustellen, dass die von Ihnen verwendeten Daten gültig sind und in der Datenbank vorhanden sind, bevor Sie versuchen, sie zu verwenden.
Wenn Sie noch einen Schritt weiter gehen möchten, können Sie die
-Klaus
where Im obigen Beispiel überprüfen wir, ob jede ID, die im exists -Array übergeben wurde, in der Spalte
$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()) {
// 一个或多个字段验证失败。
// 在此处进行处理...
} auf user_ids eingestellt ist. Wenn wir eine nicht überprüfte Benutzer -ID übergeben, schlägt die Überprüfung fehl. users
id# Überprüfen Sie die Einzigartigkeit von Feldern in der Datenbank is_verified
true Ähnlich wie bei der
Angenommen, Sie haben eine exists -Tabelle und möchten sicherstellen, dass das Feld unique eindeutig ist. Sie können
users
email Im obigen Beispiel prüfen wir, ob das Feld unique eingestellt ist, eine E -Mail ist, und ist in der Spalte
Validator::make(
data: [
'title' => 'Blog Post',
'description' => 'Blog post description',
],
rules: [
'title' => ['required', 'string', 'max:100'],
'description' => ['required', 'string', 'max:250'],
]
)->validate();
email Was passiert jedoch, wenn wir versuchen, diese Überprüfung auf einer Profilseite zu verwenden, auf der der Benutzer seine E -Mail -Adresse aktualisieren kann? Die Überprüfung schlägt fehl, da in der Tabelle users eine Zeile enthält, die die E -Mail -Adresse enthält, auf die der Benutzer zu aktualisieren versuchte. In diesem Fall können wir die Methode email verwenden, um die Benutzer -ID bei der Überprüfung der Einzigartigkeit zu ignorieren:
users Wenn Sie die Methode ignore verwenden, sollten Sie diese Warnung in der Laravel -Dokumentation lesen:
"Sie sollten niemals eine vom Benutzer kontrollierte Anforderungseingabe in die ignore -Methode übergeben. Stattdessen sollten Sie nur eine eindeutige ID übergeben, die vom System generiert wird, z.
kann es auch sein, dass Sie manchmal zusätzliche
-Regel hinzufügen möchten. Möglicherweise müssen Sie dies tun, um sicherzustellen, dass die E -Mail -Adresse für ein bestimmtes Team eindeutig ist (was bedeutet, dass ein anderer Benutzer in einem anderen Team dieselbe E -Mail verwenden kann). Sie können dies tun, indem Sie den Verschluss an die unique -Methode weitergeben: where
where
<input type="number" min="1" max="10" required>
Gott sei Dank, das ist auch in Laravel leicht zu tun!
Lassen Sie uns sehen, wie Sie benutzerdefinierte Validierungsregeln erstellen, wie Sie sie verwenden und dann Tests dafür schreiben.
Für die Zwecke dieses Artikels sind wir nicht sehr besorgt darüber, was wir überprüfen. Wir möchten nur die allgemeine Struktur des Erstellens benutzerdefinierter Validierungsregeln und zum Testen verstehen. Daher erstellen wir eine einfache Regel, um zu überprüfen, ob die Zeichenfolge Palindrome ist.
Wenn Sie es nicht wissen, ist ein Palindrom eine Folge von Wörtern, Phrasen, Zahlen oder anderen Zeichen, die das gleiche in den Vorwärts- und Rückwärtsanweisungen lesen. Zum Beispiel ist "Racecar" ein Palindrom, denn wenn Sie die Saite invertieren, ist es immer noch "Racecar". Und "Laravel" ist kein Palindrom, denn wenn Sie die Saite invertieren, ist es "Levaral".
Um zu beginnen, werden wir zunächst eine neue Validierungsregel erstellen, indem wir den folgenden Befehl in der Projektroute ausführen:
Dies sollte eine neue
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'],
]
);
App/Rules/Palindrome.php
$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()) {
// 一个或多个字段验证失败。
// 在此处进行处理...
}
validate
$attribute $value $fail
validate
Validator::make(
data: [
'title' => 'Blog Post',
'description' => 'Blog post description',
],
rules: [
'title' => ['required', 'string', 'max:100'],
'description' => ['required', 'string', 'max:250'],
]
)->validate();
$fail Jetzt, da wir die Regel erstellt haben, können wir sie in unserer App wie folgt verwenden:
Obwohl dies eine einfache Regel ist, die wir für Demonstrationszwecke erstellt haben, hoffe ich, dass dies Ihnen eine Vorstellung davon gibt, wie Sie komplexere Regeln für Ihre Anwendung erstellen können.
{
"message": "The title field is required. (and 1 more error)",
"errors": {
"title": [
"The title field is required."
],
"description": [
"The description field is required."
]
}
}Genau wie bei jedem anderen Code in Ihrer App ist es wichtig, Ihre Validierungsregeln zu testen, um sicherzustellen, dass sie wie erwartet funktionieren. Andernfalls können Sie riskieren, Regeln zu verwenden, die nicht wie erwartet funktionieren.
Um zu verstehen, wie das geht, schauen wir uns an, wie die Palindrome -Regeln, die wir im vorherigen Abschnitt erstellt haben, testen.
Für diese spezifische Regel möchten wir zwei Situationen testen:
Sie haben möglicherweise mehr Situationen in komplexeren Regeln, aber für die Zwecke dieses Artikels halten wir es einfach.
Wir erstellen eine neue Testdatei mit dem Namen tests/Unit/Rules im Verzeichnis PalindromeTest.php.
Schauen wir uns die Testdatei an, und dann werden wir diskutieren, was ausgeführt wird:
<input type="number" min="1" max="10" required>
In der obigen Testdatei definieren wir zwei Tests: rule_passes_with_a_valid_value und rule_fails_with_an_invalid_value.
Wie der Testname impliziert, stellt der erste Test sicher, dass die Regel vergeht, wenn der Wert Palindrome ist, und der zweite Test stellt sicher, dass die Regel fehlschlägt, wenn der Wert nicht Palindrome ist.
Wir verwenden das Attribut PHPUnitFrameworkAttributesDataProvider, um eine Liste gültiger und ungültiger Werte für den Test zum Testen bereitzustellen. Dies ist eine großartige Möglichkeit, Ihre Tests sauber zu halten und mehrere Werte mit demselben Test zu überprüfen. Wenn beispielsweise jemand der Methode validValues einen neuen gültigen Wert hinzufügt, wird der Test automatisch gegen diesen Wert ausgeführt.
Im Test rule_passes_with_a_valid_value verwenden wir gültige Werte, um die validate -Methode in der Regel aufzurufen. Wir übergeben den Verschluss an den Parameter fail (dieser Parameter wird aufgerufen, wenn die interne Validierung der Regel fehlschlägt). Wir haben angegeben, dass der Test fehlschlagen sollte, wenn der Verschluss ausgeführt wird (d. H. Die Überprüfung fehlgeschlagen). Wenn wir das Ende des Tests erreichen, ohne die Schließung auszuführen, wissen wir, dass die Regel bestanden hat und wir eine einfache Behauptung assertTrue(true) hinzufügen können, um den Test zu bestehen.
Im rule_fails_with_an_invalid_value -Test sind wir die gleichen wie die erste, aber diesmal übergeben wir den ungültigen Wert an die Regel. Wir haben angegeben, dass der Test bestehen, wenn der Schließung ausgeführt wird (d. H. Die Überprüfung), der Test bestehen sollte, weil wir erwarten, dass der Schließung aufgerufen wird. Wenn wir das Ende des Tests erreichen, ohne die Schließung auszuführen, werden keine Behauptungen ausgeführt und Phpunit sollte eine Warnung für uns auslösen. Wenn Sie jedoch lieber sicherstellen, dass der Test explizit fehlschlägt als nur Fehler, müssen Sie möglicherweise einen etwas anderen Ansatz zum Schreiben des Tests verfolgen.
In diesem Artikel untersuchen wir, was Überprüfung ist und warum es wichtig ist. Wir haben die clientseitige Überprüfung mit der serverseitigen Überprüfung verglichen und untersucht, warum die clientseitige Überprüfung nicht als einzige Form der Überprüfung in der Anwendung verwendet werden sollte.
Wir haben auch einige bequeme Überprüfungsregeln gemeldet, die ich in meiner Laravel -App gerne verwende. Schließlich untersuchen wir, wie Sie Ihre eigenen Validierungsregeln erstellen und sie testen, um sicherzustellen, dass sie wie erwartet funktionieren.
Ich hoffe, Sie sollten jetzt zuversichtlich genug sein, um mehr Überprüfung zu verwenden, um die Sicherheit und Zuverlässigkeit Ihrer Anwendung zu verbessern.
Das obige ist der detaillierte Inhalt vonDer ultimative Leitfaden zur Laravel -Validierung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
CSS3-Tutorial
So legen Sie ein Passwort in Windows fest
Linux-Befehl zum Umbenennen von Dateien
Lösung dafür, dass Java-Code nicht ausgeführt wird
Was sind die Grundeinheiten der C-Sprache?
Welche Plug-Ins werden benötigt, damit vscode HTML ausführen kann?
Was sind die gängigen Methoden der Datenerhebung?
Einführung in die Rolle von Cloud-Servern
![[Web-Frontend] Node.js-Schnellstart](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
