Validált, érvényesített... és érvényesített! Adatellenőrzők összehasonlítása PHP-ben. Érvényesítés és adattisztítás PHP Insane validation php segítségével

18.07.2021 Linux áttekintés

Nagyon fontos, hogy az űrlapba bevitt adatokat érvényesítsék, mielőtt az űrlap beküldési adatait további feldolgozásra felhasználná. Ha sok mező van az űrlapon, a PHP-ellenőrző szkript túl bonyolulttá válik. Ezen túlmenően, mivel ugyanazt vagy hasonló érvényesítést hajt végre a legtöbb elkészített űrlapon, túl sok ismétlődő erőfeszítést kell fordítani az űrlapellenőrzésekre.

Erről az általános PHP-űrlap-ellenőrző szkriptről

Ez az általános PHP űrlapellenőrző szkript nagyon egyszerűvé teszi az érvényesítések hozzáadását az űrlaphoz.

Az űrlap minden eleméhez létrehozunk és társítunk egy készletet „érvényesítési leírókból”. Az „érvényesítési leíró” egy karakterlánc, amely meghatározza az érvényesítés típusát. Például a „req” azt jelenti, hogy kötelező, az „alfa” azt jelenti, hogy csak alfabetikus karaktereket engedélyez és így tovább.

Az űrlap minden mezője nulla, egy vagy több érvényesítéssel rendelkezhet. Például a bemenet nem lehet üres, nem lehet 25 karakternél rövidebb, alfanumerikus stb.

Az űrlap minden beviteli mezőjéhez érvényesítési leírókészletet rendelhet.

Töltse le a PHP űrlap érvényesítő szkriptjét

Az alábbiakban letöltheti a PHP űrlap érvényesítő szkriptjét:
A zip fájl tartalmazza a formvalidator.php űrlapellenőrző szkriptet, a dokumentációt és a használati mintákat.

A PHP űrlapellenőrző szkript használata

Szerelje be a formvalidator.php fájlt az űrlapfeldolgozó szkriptbe

request_once "formvalidator.php"

Hozzon létre egy FormValidator objektumot, és adja hozzá az űrlapérvényesítési leírókat.

$validator = new FormValidator(); $validator->addValidation("Név","req","Kérem írja be a nevet"); $validator->addValidation("Email","email", "Az e-mail beviteli értéknek érvényes e-mail értéknek kell lennie"); $validator->addValidation("Email","req","Kérjük, töltse ki az e-mailt");

Az első argumentum az űrlap beviteli mezőjének neve. A második argumentum az érvényesítési leíró, amely megmondja a szükséges érvényesítés típusát. A harmadik argumentum a hibaüzenet, amely akkor jelenik meg, ha az érvényesítés sikertelen.

Érvényesítse az űrlapot a ValidateForm() függvény meghívásával

if(!$validator->ValidateForm()) ( echo "Érvényesítési hibák:"; $error_hash = $validator->GetErrors(); foreach($error_hash mint $inpname => $inp_err) ( echo "

$inpname: $inp_err

\n"; ) ) Példa

Az alábbi példa világosabbá teszi az ötletet

Név: Email:

Egyéni érvényesítés hozzáadása

Ha olyan egyéni érvényesítést szeretne hozzáadni, amelyet az érvényesítési leírók nem biztosítanak, megteheti. Íme a lépések:

Hozzon létre egy osztályt az egyéni érvényesítéshez, és írja felül a DoValidate() függvényt

class MyValidator kiterjeszti a CustomValidator ( függvény DoValidate(&$formars,&$error_hash) ( if(stristr($formars["Megjegyzések"],"http://")) ( $error_hash["Comments"]="Nincsenek URL-ek engedélyezettek megjegyzésekben"; hamis visszatérés; ) igaz visszaadás; ) )

Adja hozzá az egyéni érvényesítési objektumot

Az egyéni érvényesítési funkció automatikusan meghívásra kerül a többi érvényesítés után.

Az érvényesítési leírók táblázata

Íme az összes érvényesítési leíró lista:

Érvényesítési leíró	Használat
req	A mező nem lehet üres
maxlen=???	maximálisan ellenőrzi a bevitt adatok hosszát. Ha például a megengedett legnagyobb méret 25, akkor az érvényesítési leírót a következőképpen adja meg: „maxlen=25”
minlen=???	a beírt karakterlánc hosszát a szükséges minimumig ellenőrzi. példa „minlen=5”
alnum	Ellenőrizze az adatokat, ha az alfabetikus vagy numerikus karaktereken kívül más karaktert is tartalmaz
alnum_s	Csak alfabetikus, numerikus és szóköz karaktereket engedélyez
sz	Ellenőrizze a numerikus adatokat
alfa	Ellenőrizze az alfabetikus adatokat.
alfa_s	Ellenőrizze az alfabetikus adatokat, és hagyjon szóközt.
email	A mező egy e-mail mező, és ellenőrizze az adatok érvényességét.
lt=??? kevesebb=???	Ellenőrizze, hogy az adatok kisebbek-e az átadott értéknél. Csak numerikus mezőkre érvényes. példa: ha az értéknek 1000-nél kisebbnek kell lennie, adja meg az érvényesítési leírást „lt=1000”
gt=??? nagyobb mint=???	Ellenőrizze, hogy az adatok nagyobbak-e az átadott értéknél. Csak numerikus mezőkre érvényes. példa: ha az értéknek 10-nél nagyobbnak kell lennie, adja meg az érvényesítés leírását "gt=10"
regexp=???	Ellenőrizze egy reguláris kifejezéssel, hogy az értéknek meg kell egyeznie a reguláris kifejezéssel. példa: „regexp=^(1.20)$” legfeljebb 20 alfabetikus karaktert engedélyez.
ne válassz=??	Ez az érvényesítési leíró a kiválasztott beviteli elemekhez (listákhoz) szolgál. Általában a kijelölő listamezőkben van egy elem, amely „Válasszon egyet” felirattal. A felhasználónak ettől eltérő opciót kell választania. Ha ennek az opciónak az értéke „Select One”, akkor az érvényesítés leírása „dontselect=Select One” legyen.
dontselectchk	Ez az érvényesítési leíró a jelölőnégyzetekre vonatkozik. A felhasználó ne jelölje be a megadott négyzetet. Adja meg a jelölőnégyzet értékét a ?? Például dontselectchk=on
kellene választani	Ez az érvényesítési leíró a jelölőnégyzetekre vonatkozik. A felhasználónak be kell jelölnie a megadott jelölőnégyzetet. Adja meg a jelölőnégyzet értékét a ?? Például shouldselchk=on
ne válassza ki a rádiót	Ez az érvényesítési leíró a választógombokra vonatkozik. A felhasználó ne válassza ki az adott választógombot. Adja meg a rádiógomb értékét a ?? Például: dontselectradio=NO
válasszon rádiót	Ez az érvényesítési leíró a választógombokra vonatkozik. A felhasználónak ki kell választania az adott rádiógombot. Adja meg a rádiógomb értékét a ?? Például selectradio=yes
selmin=??	Jelöljön ki legalább n számú jelölőnégyzetet egy jelölőnégyzetcsoportból. Például: selmin=3
Selone	Kötelezővé tesz egy rádiócsoportot. A felhasználónak ki kell választania legalább egy elemet a rádiócsoportból.
eqelmnt=???	Hasonlítsa össze az űrlap két elemét, és győződjön meg arról, hogy az értékek megegyeznek. Például: „jelszó” és „jelszó megerősítése”. Cserélje ki a ??? a másik beviteli elem nevével. Például: eqelmnt=confirm_pwd

Egy korábbi cikkben megígértem, hogy összehasonlítom saját könyvtáram más elérhető megoldásokkal, ezért ma az Aura.Filter, Respect Validation, Sirius Validation és Valitron segítségével történő érvényesítést fogjuk megvizsgálni.

Képzeljük el, hogy van egy bizonyos közszolgáltatásunk fejlesztés alatt, amely magában foglalja a felhasználók regisztrációját teljes hozzáférés minden funkcióhoz. Így a regisztrációs űrlap a következő mezőket tartalmazza:

név. Pontosan két szót kell tartalmaznia, ahol az első a felhasználó keresztneve, a második pedig a vezetéknév.

bejelentkezés. Ha átadott egy értéket, az csak latin betűket, kötőjeleket és aláhúzásjeleket tartalmazhat.

email. Érvényes címet kell tartalmaznia email.

jelszó. Be kell állítani, és nem lehet hosszabb 64 karakternél.

egyeztetett. Tipikus jelölőnégyzet, amelyet a felhasználónak be kell jelölnie, hogy megerősítse, hogy elfogadja a szolgáltatási feltételeket.

Tehát öt mezőnk van, amelyeket a felhasználónak ki kell töltenie, hogy regisztráljon képzeletbeli szolgáltatásunkba. Képzeljük el, hogy teljesen érvénytelen adatokat kaptunk bemenetként:

$data = [ "name" => "Albert", // Két szónak kell lennie "login" => "@lbert", // "Tiltott" karakter @ "email" => "valami baj van", / / Ott kell lennie legyen egy e-mail "jelszó" => Aura.Filter

Az Aura.Filter használatával történő érvényesítés a szűrőgyárral kezdődik. Létre kell hoznunk egy úgynevezett „tárgyszűrőt”, mivel egy tömböt fogunk érvényesíteni, nem pedig egy egyedi értéket.

A szabályokat az Aura\Filter\FilterFactory használatával határozzuk meg; $filter = (új FilterFactory)->newSubjectFilter(); $filter->validate("név") ->isNotBlank() ->is("két_szó") ->setMessage("A névnek két szóból kell állnia."); $filter->validate("bejelentkezés") ->isBlankOr("alnum") ->setMessage("Ha megad egy bejelentkezést, annak csak latin karaktereket kell tartalmaznia."); $filter->validate("email") ->isNotBlank() ->is("e-mail") ->setMessage("Adjon meg egy érvényes e-mail címet."); $filter->validate("jelszó") ->isNotBlank() ->is("strlenMax", 64) ->setMessage("Kérjük, írja be a jelszavát."); $filter->validate("agreed") ->is("visszahívás", function($subject, $field) ( return $subject->($field) === true; ))->setMessage("Szükséged van elfogadja a szolgáltatási feltételeket.");

Mint látható, a szabályok leírása meglehetősen egyszerű. Az Aura.Filter egy sor hasznos szabályt kínál, amelyek közül néhányat a fenti példában használtunk:

isNotBlank módszer.

Megadja, hogy a mezőnek nem lehet null értéke.

alnum.

Ez a szabály csak a latin betűket engedélyezi.

email. És ez így egyértelmű :) strlenMax. Megadja, hogy a mező nem haladhatja meg az is metódus második argumentumában megadott hosszt.

Valószínűleg észrevette, hogy nem adtam meg a two_words szabályt. Természetesen az Aura.Filterben nincs ilyen szabály, ezért létre kell hoznunk egyet. Ahogy a dokumentáció mondja, ez egy külön osztály használatával történik a szabályhoz:

/** * A felhasználónevet érvényesítő szabály.

* A felhasználónév két szóból áll: keresztnév és vezetéknév, egy szóközzel elválasztva.

*/ class UserNameRule ( /** * Érvényesíti a felhasználónevet. * * @param object|tömb $subject * @param string $field * @param int $max * * @return bool */ public function __invoke($subject, $field , $max = null) ( $érték = $tárgy->($mező); if (! is_scalar($value)) ( return false; ) return (bool) preg_match("/^+\s+$/u", $érték);

A második lépés, hogy értesítsük a szűrőgyárat az új szabályunkról. Ez úgy történik, hogy az első argumentumot szabálytömbként adjuk át a szűrőgyárnak:

A következő lépés az Aura.Filter értesítése, hogy új szabályt hoztunk létre és használni akarjuk. Ez úgy történik, hogy egy szabálytömböt adunk át a gyár első argumentumának:

az Aura\Filter\FilterFactory használata; $rules = [ "két_szó" => function() ( return new UserNameRule; ) ]; $filter = (new FilterFactory($rules))->newSubjectFilter();

Most a két_szó szabályunk ugyanúgy használható, mint bármely más szabványos szabály.

Visszacsatolás

Mint emlékszik, az általunk ellenőrzött bejövő adatok teljesen érvénytelenek, mert minden mező hibás értéket tartalmaz, vagy egyáltalán nem tartalmazza. Ezért feltételezzük, hogy az érvényesítés eredményeként hibákat és azokról szóló üzeneteket kapunk.

Az Aura.Filterrel az alábbiak szerint érvényesítjük: $érvényes = $filter->apply($data); if (! $érvényes) ( $hibák = $filter->getFailures(); $üzenetek = $hibák->getMessages(); ) IN

$üzenetek

egy tömb íródik, így az üzenetek megjelenítéséhez két egymásba ágyazott foreach szükséges:

Tartsa tiszteletben az érvényesítést

használja a Respect\Validation\Validatort v; $data = [ "name" => "Albert", // Két szónak kell lennie "login" => "@lbert", // "Tiltott" karakter @ "email" => "valami baj van", / / Ott kell lennie be an e-mail here "password" => "" // A jelszó egyáltalán nincs megadva // "Agreed" nincs a tömbben, mert a felhasználó nem jelölte be a négyzetet ];

A szabályok meghatározása

Az Aura.Filterhez hasonlóan a felhasználónévhez saját érvényesítési szabályra van szükségünk, tehát kezdjük ott:

névtér MyNamespace; használja a Respect\Validation\Rules\AbstractRule; osztály UserNameRule kiterjeszti az AbstractRule-t ( nyilvános függvény validate($input) ( return (bool) preg_match("/^+\s+$/u", $input); ) )

A külső szabályok API szinte teljesen megegyezik az Aura.Filter-rel, csak a valide() metódust használjuk az __invoke() varázslat helyett. Számomra ez az API egyszerűbbnek és érthetőbbnek tűnt. Nos, közelebb van a Kontrolióhoz :).

A dokumentációban nem találtam erre utalást, azonban magán a szabályon kívül saját kivételtípust kell hozzá létrehozni. A kivételosztály nevének a szabályosztály nevéből és egy postfixből kell állnia

Kivétel

használja a Respect\Validation\Exceptions\NestedValidationException; osztály UserNameRuleException kiterjeszti a NestedValidationException kivételt ( // )

Nos, végre érvényesíthetjük adatainkat. Először is átadjuk az új szabályunkat az érvényesítőnek, hogy ő tudjon róla, és a jövőben használhassuk. A Respect Validation esetén ez a with() metódus meghívásával történik, átadva azt a névteret, amelyben a nem szabványos szabályok találhatók. v::with("SajátNévter\\"); Most minden nem szabványos szabály a névtérben található

MyNamespace

, az érvényesítő „felismeri”. A következő lépés a szükséges szabályok leírása és az érvényesítés végrehajtása. v::attribute("name", v::userNameRule()) ->attribute("bejelentkezés", v::alnum("-_")) ->attribute("email", v::email()) ->attribute("jelszó", v::notEmpty()->stringType()->length(null, 64)) ->attribute("agreed", v::trueVal()) ->assert((objektum) $adat); Figyeljük meg, hogyan alkalmazzuk a szabályunkat az attribútumra

név . Itt a szabályosztály neve a validátor metódus nevévé alakult. A többi szabály általában intuitív. Külön érdemes megemlíteni, hogy miért adjuk meg a tömböt

az Aura\Filter\FilterFactory használata; $rules = [ "két_szó" => function() ( return new UserNameRule; ) ]; $filter = (new FilterFactory($rules))->newSubjectFilter();

Az Aura.Filtertől eltérően a Respect validator kivételt dob, ha az ellenőrzés sikertelen. És ez a kivétel érvényesítési hibaüzeneteket tartalmaz. Ezért az imént bemutatott példát a következőképpen kell írni:

try ( v::with("RespectValidationExample\\"); v::attribute("name", v::userNameRule()) ->attribute("bejelentkezés", v::alnum("-_")) - >attribute("e-mail", v::email()) ->attribute("jelszó", v::notEmpty()->stringType()->length(null, 64)) ->attribute("agreed", v::trueVal()) ->assert((object) $data ) catch (NestedValidationException $ex) ( $üzenetek = $ex->getMessages(); )

A getMessages() használatával egy lapos tömböt kapunk az összes üzenetből, amelyet az érvényesítő gyűjtött az ellenőrzési folyamat során. A tömb kiíratásával valami ilyesmit kapunk:

array(5) ( => string(29) “A(z) %s adatellenőrzése nem sikerült” => string(60) “a bejelentkezés csak betűket (a-z), számjegyeket (0-9) és "-_" => karakterláncot tartalmazhat (25) "e-mail kell lennie érvényes e-mail" => string(26) "jelszó nem lehet üres" => string(32) "A megállapodott attribútumnak jelen kell lennie" )

Módosíthatja az üzeneteket a sajátjára. Lehet, hogy valahogy félreértettem ezt a könyvtárat, de ez a folyamat nem tűnt számomra annyira magától értetődőnek: egy kezelt kivételnél a findMessages() metódust kell használni, amelyben nem attribútumokhoz, hanem szabályokhoz definiálsz üzeneteket.

$ex->findMessages([ "userNameRule" => "A felhasználónévnek két szóból kell állnia.", "alnum" => "Nem tetszik nekünk a bejelentkezésed.", "email" => "Nyilvánvalóan nem szeretné átadni nekünk az e-mail címét.", "notEmpty" => "Nos, hol a jelszava?", "agreed" => "Kár, hogy nem ért egyet." ]);

Nem tudom mi a baj, de van pár dolog, amit még mindig nem értek. Ezt kapjuk, ha a szabályokat a fenti módon határozzuk meg:

array(5) ( => string(40) "A felhasználónévnek két szóból kell állnia." => string(31) "Nem tetszik a bejelentkezésed." => string(25) "Az e-mail-címnek érvényes e-mail-címnek kell lennie" = > string(5) "Nos, hol van a jelszavad?" => string(9) "Kár, hogy nem értesz egyet."

Amint látja, az e-mail mezőhöz tartozó üzenetet nem alkalmazták, a normál maradt. De a 4-es index üzenete ennek az ellenkezője! És ez annak ellenére, hogy nem a szabály nevét használtam, hanem a mező nevét. Míg ha a szabálynevet (trueVal) használtam volna, az üzenetem valahol elveszett volna. Nagyon várjuk a könyvtár tapasztalt felhasználóinak észrevételeit.

Sirius érvényesítés

Ok, menjünk tovább a következő könyvtárra, és nézzük meg, hogyan kezeli a hasonló feladatokat.

A szabályok meghatározása

Ismét meg kell határoznunk egy szabályt a felhasználónévhez. Valahogy így írjuk:

class UserNameRule kiterjeszti AbstractRule-t ( // Hibaüzenetek const MESSAGE = "A felhasználónévnek két szóból kell állnia."; const LABELED_MESSAGE = "(címke) két szóból kell állnia."; public function valide($value, $valueIdentifier = null ) ( return (bool) preg_match("/^+\s+$/u", $érték ) )

Kérjük, vegye figyelembe a megközelítések különbségét a már tárgyalt könyvtárakhoz képest. Kétféle üzenetet definiálunk konstansokban, nem pedig tulajdonságokat, metódusokat vagy szabály argumentumokat használunk.

Most pedig írjuk le az érvényesítési logikát:

$validator = új Validator; $validator ->add("név", "kötelező | MyApp\Validation\Rule\UserNameRule") ->add("bejelentkezés", "szükséges | alphaumhyphen", null, "A bejelentkezés csak latin betűket, kötőjeleket és aláhúzásjeleket tartalmazhat. ") ->add("e-mail", "szükséges | e-mail", null, "Kérjük, adjon meg helyes e-mailt.") ->add("jelszó", "szükséges | maxlength(64)", null, "Az Ön jelszó, uram.") ->add("egyetértek", "kötelező | egyenlő(igaz)", null, "Miért nem értett egyet?");

Amint látja, a szabályrendszer nagyon egyszerű és olvasható. A leíráshoz vízszintes sávokkal elválasztott neveket használunk. Ez a megközelítés hasonló a Laravel és a Kontrolio által használthoz.

Az add() metódus negyedik argumentuma azt az érvényesítési hibaüzenetet írja le, amelyet a Sirius használ, ha az ellenőrzés sikertelen. Miért nem adtunk hozzá üzenetet az új szabályunkhoz? Felhasználónévszabály?

$validator->add("név", "kötelező | MyApp\Validation\Rule\UserNameRule")

Ennek az az oka, hogy az üzenetek már le vannak írva az osztálykonstansokban:

class UserNameRule extends AbstractRule ( // Error messages const MESSAGE = "A felhasználónévnek két szóból kell állnia."; ...

Egy másik lehetőség az érvényesítő addMessage() metódusának használata:

$validator->addMessage("e-mail", "Adjon meg egy érvényes e-mailt.");

Kérjük, vegye figyelembe, hogy az egyéni szabályokat az osztály teljes neve azonosítja, míg a Kontrolio-ban megadhat álnevet/álnevet.

az Aura\Filter\FilterFactory használata; $rules = [ "két_szó" => function() ( return new UserNameRule; ) ]; $filter = (new FilterFactory($rules))->newSubjectFilter();

Az érvényesítés végrehajtásához meghívjuk a validate() validátor metódust, és átadjuk neki az adatokat:

A Respect-tel ellentétben Sirius nem tesz kivételt, hanem egyszerűen visszatér hamis. Az érvényesítési hibaüzenetek a getMessages() validátor metóduson keresztül érhetők el. A hibákat attribútumok szerint csoportosítva adja vissza, így két foreach ciklusra van szükségünk a hibák áthaladásához:

foreach ($validator->getMessages() mint $attribútum => $üzenetek) ( foreach ($messages mint $üzenet) ( echo $message->getTemplate() . "\n"; ) )

Itt a $message egy osztályobjektum Sirius\Validation\ErrorMessage, amelynek van egy getTemplate() metódusa, amely pontosan azt az üzenetet adja vissza, amelyre szükségünk van.

Valitron A szabályok meghatározása

Az első különbség: új szabály hozzáadásához nem kell külön osztályt létrehoznia. Egyszerűen használhat olyan lezárást, amely logikai eredményt ad vissza.

Egyéni szabályok hozzáadásához a Valitron rendelkezik egy statikus addRule() metódussal, amelyben az első két argumentum kötelező, a harmadik pedig nem kötelező. Tetszett ez a módszer, hiszen itt egy helyen van feltüntetve a szabályazonosító, a logika és a hibaüzenet.

használja a Valitron\Validatort; Validator::addRule("két_szó", function($field, $value) ( Return (bool) preg_match("/^+\s+$/u", $value); ), "A felhasználónévnek pontosan a következőkből kell állnia két szó ");

A második különbség az, hogy a szabályokat hogyan alkalmazzák az attribútumokra. Minden korábbi esetben azt láttuk, hogy egy attribútum mintegy elsődleges dolog.

A Valitron más utat választott, és az érvényesítési szabályokat helyezte előtérbe. A szabályok leírásával úgy tűnik, hogy attribútumokat alkalmaz ezekre a szabályokra, és nem fordítva.

$validator = new Validator($data); $validator ->rule("two_words", "name")->label("") ->rule("kötelező", [ "név", "bejelentkezés", "e-mail", "jelszó", "megegyezett" ] ) ->rule("slug", "bejelentkezés") ->rule("e-mail", "e-mail") ->rule("elfogadva", "elfogadva");

Ahogy a példából is látható, a rule() metódusban először a szabály nevét írjuk be, és csak ezután jelöljük meg azokat az attribútumokat, amelyeknek meg kell felelniük ennek a szabálynak. Explicitebb példa a kötelező szabály, amely megmutatja, hogy az attribútumok hogyan „tartoznak” ehhez a szabályhoz.

A Valitron (a többi általunk áttekintett megoldáshoz hasonlóan) szabványos hibaüzeneteket biztosít. Ha csak használja őket, látni fogja, hogy minden üzenet a megfelelő attribútum nevével kezdődik.

A Valitron attribútumneveket helyettesít az üzenet szövegében, még akkor is, ha nem szabványos hibaüzeneteket használnak. Ezért használtuk a label() metódust üres karakterlánccal az attribútum nevének eltávolításához.

$validator->rule("két_szó", "név")->címke("") Visszajelzés

Konkrétan az érvényesítést illetően a Valitron könyvtár API gyakorlatilag nem különbözik attól, amit a cikkben már láthattunk. Az érvényesítés végrehajtásához meghívjuk a validate() validátor metódust:

$validator->validate();

Az érvényesítési hibaüzenetek a getErrors() metódussal kérhetők le:

$validator->errors();

Az üzenetek itt ugyanúgy vannak attribútumok szerint csoportosítva, mint a Sirius Validationben, azzal a különbséggel, hogy az üzenetnek nincs külön osztálya, és egy szabályos többdimenziós tömböt kapunk.

foreach ($validator->errors() mint $attribútum => $üzenetek) ( foreach ($üzenetek mint $üzenet) ( echo $message . "\n"; ) ) Kontrolio

És végül, a mai nap utolsó könyvtára a Kontrolio nevű saját fejlesztésem.

A szabályok meghatározása

Ismét ötödik alkalommal hozunk létre egy érvényesítési szabályt a felhasználónévhez. Minden viszonylag egyszerű és szabványos:

névtér MyProject\Validation\Rules; használja a Kontrolio\Rules\AbstractRule; osztály TwoWords kiterjeszti Kontrolio\Rules\AbstractRule ( nyilvános függvény isValid($input = null) ( return (bool) preg_match("/^+\s+$/u", $input); ) )

Most létrehozunk egy gyárat és regisztrálunk benne egy szabályt az extend() metódussal:

névtér MyProject; a Kontrolio\Factory használata; a MyProject\Validation\Rules\TwoWords használata; $factory = Kontrolio\Factory::getInstance()->extend();

A szabály regisztrálása után használhatjuk, név szerint is - two_words. Hozzunk létre egy érvényesítőt:

$data = [ "name" => "Albert", // Két szónak kell lennie "login" => "@lbert", // "Tiltott" karakter @ "email" => "valami baj van", / / Ott kell lennie be an e-mail here "password" => "" // A jelszó egyáltalán nincs megadva // "Agreed" nincs a tömbben, mert a felhasználó nem jelölte be a négyzetet ]; $rules = [ "név" => "két_szó", "login" => "néha|alphadash", "e-mail" => "e-mail", "jelszó" => "hossz:1,64", "egyetértek" = > " elfogadva" ]; $messages = [ "name" => "A felhasználónévnek két szóból kell állnia.", "login" => "Nem tetszik a bejelentkezésed.", "email" => "Nyilvánvalóan nem akarod megadni us your email .", "password" => "Nos, hol a jelszava?", "agreed" => "Kár, hogy nem ért egyet." ]; $validator = $gyári->make($adat, $szabályok, $üzenetek);

A szabályokat a Laravelben használt szintaxissal írtuk le, bár használhattunk volna egy bőbeszédű verziót is:

$rules = [ "név" => new TwoWords, "login" => , "email" => new Email, "password" => new Length(1, 64), "agreed" => new Elfogadva ];

Visszacsatolás

$validator->validate();

Az érvényesítés ugyanazzal a validate() metódussal indul:

Most a getErrors() vagy getErrorsList() metódusok valamelyikével kaphatunk hibaüzeneteket. Az első módszer bonyolultabb hibakimenetet tesz lehetővé, míg a második egy lapos tömböt ad vissza. A getErrors() segítségével a következő üzeneteket tudjuk kiadni:

A getErrorsList() segítségével pedig egyszerűbb üzenetlistát készíthet:

A lényeg

Ebben a cikkben példákat mutattam be a következő könyvtárak használatára:

Aura.Szűrő

Sirius érvényesítés

Tartsa tiszteletben az érvényesítést

Valitron

ellenőrzés

Egy „valódi példa” túl egyszerűnek tűnhet. Egyet kell értenem, mert valóban, néhány könyvtári lehetőség kimaradt a cikkből. Elvileg, ha érdekli, saját maga is tanulmányozza a jellemzőit.

Mindegyik könyvtárnak megvan a maga sajátossága, és megvannak a sötét oldalai is, úgyhogy szerintem ízlés és kihívás a megfelelő kiválasztása.

Köszönöm, hogy elolvastad. Válasszon helyesen.

Címkék: Címkék hozzáadása

Jó estét mindenkinek (inkább éjszakát – a szerkesztő megjegyzése). Ma egy kicsit javítunk ezen. Először is, tanuljuk meg, hogyan kell végrehajtani az űrlap érvényesítését PHP-ben, és hajtsunk végre néhány biztonsági manipulációt.

Tehát nézze meg az alábbi kódot, és vegye figyelembe a következő változtatásokat és a változtatások alábbi okait. Minden új vonalat színnel kiemeltem.

Az űrlapmezők neve megváltozott. Felmerülhet a kérdés: mi a fenének van erre szükségünk? Egyszerű, válaszolok. Amennyire én tudom, egyes spamrobotok átkutatják az űrlapokat kereső webhelyeket, és e mezők neve alapján töltik ki azokat. Elméletileg, ha nem találnak megfelelőt, akkor hazamennek, amit mi akarunk. Természetesen nem hiszem, hogy ez a védelem különösen nagy, de nekünk nem árt, és ha a spam e-mailek száma 1 betűvel csökken, az jó lesz =). Ellenőrizze, hogy az e-mail cím helyesen van-e megadva. A 17. sor az elseif operátort használja, amit akkor ellenőriznek, ha pozitív választ adnak vissza nekünk, vagyis azt mondták, hogy az email cím egyáltalán hiányzik, vagyis nem adta meg. Itt a preg_match függvényt használjuk, amely lehetővé teszi a megadott cím összehasonlítását reguláris kifejezés . Talán később írok röviden a reguláris kifejezésekről, de ezt most érdemes tudni létrehoz egy sablont, amelyhez képest a karakterláncunkat ellenőrzi. És ha esetünkben a megadott cím nem egyezik a kifejezéssel, akkor ismét hibaüzenet jelenik meg. Például itt van még néhány reguláris kifejezés:
|^[-а-яе\s\.,;:\?!]+$|i– ez a reguláris kifejezés csak az orosz ábécé és néhány karakter, például szóköz, pont, vessző stb. használatát teszi lehetővé.
#http://[-a-z0-9_.]+[-a-z0-9_:@&?=+,.!/~*’%$]*\.(html?|php)#i– és ez a kifejezés lehetővé teszi egy cím helyesírásának ellenőrzését az interneten.

Ezután az else operátort használjuk, ahol már az összes levélküldéshez szükséges kódunk át lett helyezve. Bármilyen mennyiségben létrehozhat saját maga ellenőrzési szabályokat, csak adjon hozzá újakat, például egy e-mail-cím ellenőrzéséhez, és boldog lesz.

Kapcsolattartó személy:

Kapcsolattartási e-mail:

Üzenet:

Így érvényesítheti a PHP űrlapjait anélkül, hogy bármi idegenhez folyamodna. Legközelebb az űrlapok témájával foglalkozó bejegyzésben azt hiszem, az űrlapok jQuery-ben való érvényesítése is szóba kerül majd. Addig is várom észrevételeiteket, kívánságaitokat. Jó éjszakát és jó reggelt mindenkinek =).

Szó lesz a POST vagy GET adatok érvényesítéséről, bár ez elvileg más módszerekkel, például cookie-kkal kapott adatokra is alkalmazható. Bármely webalkalmazás fejlesztése során létre kell hoznia egy felületet a felhasználókkal való interakcióhoz, és természetesen különféle űrlapokat kell létrehoznia a felhasználók számára, hogy adatokat küldhessenek a szerverre. például ezek lehetnek megjegyzések. Szerintem mindenki számára egyértelmű és nyilvánvaló, hogy a kapott adatokat ellenőrizni kell, hogy megfelel-e a típusnak, méretnek és meghatározott tartománynak. Ez elsősorban a rendszer, weboldal vagy adatbázis biztonsága miatt szükséges, mert... A helytelenül továbbított adatok vagy a szándékosan rosszul formált kérés hozzáférést nyithat a támadó számára.

Másodszor, az ellenőrizetlen adatok, ha hibásak, instabil működést okozhatnak a szkriptben, a rendszerben vagy az egész szerverben. Ezért minden adatot ellenőrizni kell, és talán valaki azt mondja, hogy nincs szükség túlzott paranoiára, de úgy gondolom, hogy ez egyszerűen nem lehet túlzó.

Ne bízzon a felhasználóktól kapott adatokban semmilyen ürüggyel, semmilyen körülmények között. Megesik, hogy egyszerűen lusták vagyunk a kapott adatokat még egyszer ellenőrző kódot írni, vagy reméljük meglévő módszereket elég az ellenőrzés, aminek következtében engedményeket teszünk magunknak.

Egy kis kitérő a témához:
A projekteken való munka, a weboldalak, scriptek és egyéb rendszerek fejlesztése, programozása (a munkaidőn kívül) szinte az összes szabadidőmet lefoglalja, vagyis napi maximális óraszámban végzem ezt a munkát. Időről időre szükség van egy tesztelésre, szórakozásból vagy csak kíváncsiságból. Ennek eredményeként a sebtében, házi készítésű motorokkal vagy az ősi verziójú CMS-ekkel készült oldalak hasonló tesztelő laboratóriumi patkányokká válnak. Természetesen a fentiek mindegyike szenved a ferdén megírt kódtól, az adatkezelés hiányától és egyszerűen hemzseg a különféle hibáktól. Valójában az esetek többségében az ilyen oldalakon végzett kísérleteim egy órája alatt több súlyos sebezhetőséget is sikerül találnom, és ezek többsége a beérkező adatok elégtelen validálásában rejlik. IN utóbbi időben Ez gyakran megtalálható azokban a szkriptekben, amelyek a JavaScript + Ajax-ból származó POST-adatokat dolgozzák fel.

Úgy tűnik, a programozók, akik ezeket a szkripteket Ajax segítségével írták, úgy gondolják, hogy mivel minden kérés a háttérben történik, a felhasználó tudta nélkül vagy egyszerűen az oldal újratöltése nélkül, ezért az adatokat nem kell különösebben ellenőrizni.

Általában jó néhány ilyen szkript annyira lyukasnak bizonyul, hogy különösebb erőfeszítés nélkül sikerül nagyobb lyukat csinálniuk, és elárasztani a héját. természetesen kizárólag kísérletezés céljából, és semmi több (az ilyen oldalak adminisztrációja mindig értesül a meglévő sebezhetőségekről).

Úgy gondolom, hogy az érvényesítés fontossága mindenki számára világos. Sokáig minden alkalommal ugyanazt a kódrészletet írtam, majd saját adatellenőrzési függvényeimet használtam, amelyek közül sok nagyon primitív és általában szétszórt volt. különböző részek(csatolt) fájlok. Hamarosan elkezdtem megismerkedni a Zend, CI, Kohana PHP keretrendszerekkel, amelyek mindegyike saját osztályt valósított meg a projektjeimhez kölcsönzött adatok validálására. Végül úgy döntöttem, hogy az egyik CI órát az én igényeimre szabom, de kiderült, hogy az egyik programozási blog szerzője már gondoskodott erről. Ezután megosztom a munkáit, nevezetesen a módosított CodeIgniter könyvtárat.

Nézzük a következő kódot:

Kód megtekintése PHP

request_once "validator.class.php" ;

$validator = new Validator() ; $validator -> set_rules ("név" , "Az Ön neve" , tömb ("szükséges" => , "alpha" => ) ) ;$validator -> set_rules ("e-mail" , "E-mail címed" , tömb ("required" => "%s mező kötelező" , "valid_email" => ) ) ; if ($validator -> run () ) ( echo "Az ellenőrzés sikeres volt" ; ) else ( echo $validator -> get_string_errors () ; ).
Ahogy a példából is látható, az első sorban az osztályfájlt foglaljuk validator.calss.php forgatókönyvünkhöz. Ezután létrehozzuk az osztály példányát, és elmentjük az objektumot egy változóba

$validator

Ezután a módszer segítségével$validator->set_rules($field, $label, $rules)

állítsa be az érvényesítéshez szükséges mezőket. Ez a módszer 3 paramétert igényel:

$mező- az érvényesítési mező neve (a név attribútum értéke a címkében)

$label - az érvényesítési mező neve, bekerül a hibaüzenetek közé$szabályok - érvényesítési szabályok tömbje, amelyben az érvényesítési szabályt használják kulcsként, és ennek a szabálynak a hibaüzenetét használják értékként Miután az összes érvényesítési mezőt beállítottuk, elindítjuk a validátort a metódus segítségével $validator->run().

. Ha az érvényesítés sikeres volt, ez a módszer visszaadja az értéket

IGAZ, ellenkező esetben, ha vannak hibák, akkor visszatér

HAMIS Három módja van a hibaüzenetek fogadásának:

get_string_errors()- az összes hibaüzenetet karakterláncként adja vissza

get_array_errors() — az összes üzenetet tömbként adja vissza, ahol a mező neve kulcsként, és a mező hibaleírása lesz az érték. form_error($mező)- hibaüzenetet ad vissza a $field paraméterként átadott mezőre vonatkozóan

Alapértelmezés szerint a hibaüzenetek egy címkébe vannak csomagolva . A terv beállításához használja a módszert set_error_delimiters($előtag, $utótag) . Például így:

Most a hibaüzenetek a következőre változnak

Kód megtekintése PHP

div

osztállyal "hiba" Amint látja, minden nagyon egyszerű.

Kód megtekintése PHP

$rules = array ( array ( "field" => "name" , "label" => "Az Ön neve" , "rules" => array ( "szükséges" => "A %s mező kötelező" , "alpha" = > "A %s mezőnek csak betűket kell tartalmaznia" ) , array ( "field" => "email" , "label" => "Your email" , "rules" => array ( "required" => "A % s mező kötelező" , "valid_email" => "A %s mezőnek érvényes e-mail címet kell tartalmaznia" ) ) ) ;

$validator -> set_rules ($szabályok ) ;

Mint látható, ugyanazokat az érvényesítési szabályokat írtam le, mint az első példában, csak egy többdimenziós asszociatív tömb formájában. Az adott helyzetben az Ön számára legmegfelelőbb módszerek bármelyikét használhatja.

Tehát milyen érvényesítési szabályokat támogat ez az osztály? Elhoztam erre az órára a leggyakoribb érvényesítési szabályokat, amelyekkel mindenki találkozik. Itt teljes lista

ezeket a szabályokat:	kívánt
A FALSE értéket adja vissza, ha a mező üres	egész szám
A FALSE értéket adja vissza, ha az érték nem egész szám	úszó
A FALSE értéket adja vissza, ha az érték nem numerikus érték	érvényes_url
A FALSE értéket adja vissza, ha az érték nem érvényes URL	érvényes_e-mail
A FALSE értéket adja vissza, ha az érték nem érvényes e-mail cím	érvényes_ip
A FALSE értéket adja vissza, ha az IP-cím nem érvényes	mérkőzések
A FALSE értéket adja vissza, ha az elem nem egyezik egy másik mezőelem értékével	alfa
A FALSE értéket adja vissza, ha az elem nem csak betűket tartalmaz	valid_captcha
A FALSE értéket adja vissza, ha a munkamenet mező értéke nem egyenlő az űrlapmező értékével	érvényes_dátum

A FALSE értéket adja vissza, ha az elem érvénytelen dátumot tartalmaz

A legtöbb szabály szűrőket használ, amelyek a PHP 5-ben váltak elérhetővé.

Ha szeretné, bármikor bővítheti az érvényesítés szabályait, ha a szükséges függvényeket hozzáadja a Validator osztályhoz.

Kód megtekintése PHP

A feldolgozott POST adatérték lekéréséhez használja a következő módszert:

Ezt a módszert általában az űrlap törlésére hívják az űrlap sikeres feldolgozása után.

név. Pontosan két szót kell tartalmaznia, ahol az első a felhasználó keresztneve, a második pedig a vezetéknév.

bejelentkezés. Ha átadott egy értéket, az csak latin betűket, kötőjeleket és aláhúzásjeleket tartalmazhat.

Képzeljük el, hogy van egy bizonyos közszolgáltatásunk fejlesztés alatt, amely megköveteli, hogy a felhasználók regisztráljanak az összes funkcióhoz való teljes hozzáféréshez. Így a regisztrációs űrlap a következő mezőket tartalmazza:

jelszó. Be kell állítani, és nem lehet hosszabb 64 karakternél.

egyeztetett. Tipikus jelölőnégyzet, amelyet a felhasználónak be kell jelölnie, hogy megerősítse, hogy elfogadja a szolgáltatási feltételeket.

$data = [ "name" => "Albert", // Két szónak kell lennie "login" => "@lbert", // "Tiltott" karakter @ "email" => "valami baj van", / / Ott kell lennie legyen egy e-mail "jelszó" => Aura.Filter

Mint látható, a szabályok leírása meglehetősen egyszerű. Az Aura.Filter egy sor hasznos szabályt kínál, amelyek közül néhányat a fenti példában használtunk:

isNotBlank módszer.

Megadja, hogy a mezőnek nem lehet null értéke.

alnum.

Ez a szabály csak a latin betűket engedélyezi.

email. Érvényes e-mail címet kell tartalmaznia.