Exploateringsförsöket misslyckas och ingen skada är skedd!

Validera formulärdata med PHP

Det första vi kommer att göra är att skicka alla variabler genom PHPs htmlspecialchars() funktion.

När vi använder funktionen htmlspecialchars(); sedan om en användare försöker skicka in följande i ett textfält:

Detta skulle inte köras, eftersom det skulle sparas som HTML-kodad kod, så här:

Koden är nu säker att visas på en sida eller i ett e-postmeddelande.

Vi kommer också att göra ytterligare två saker när användaren skickar in formuläret:

1. Ta bort onödiga tecken (extra blanksteg, tab, nyrad) från användarens indata (med PHP trim()-funktionen)
2. Ta bort snedstreck (\) från användarens indata (med PHP stripslashes()-funktionen)

Nästa steg är att skapa en funktion som gör all kontroll åt oss (vilket är mycket bekvämare än att skriva samma kod om och om igen).

Vi kommer att namnge funktionen test_input().

Nu kan vi kontrollera varje $_POST-variabel med funktionen test_input() och skriptet ser ut så här:

exempel

// definiera variabler och ställ in på tomma värden
$name = $email = $gender = $comment = $website = "";

if ($_SERVER["REQUEST_METHOD"] == "POST") (
$namn = test_input($_POST["namn"]);
$email = test_input($_POST["e-post"]);
$website = test_input($_POST["webbplats"]);
$comment = test_input($_POST["kommentar"]);
$gender = test_input($_POST["kön"]);
}

function test_input($data) (
$data = trim($data);
$data = stripsslashes($data);
$data = htmlspecialchars($data);
returnera $data;
}
?>

Observera att i början av skriptet kontrollerar vi om formuläret har skickats med $_SERVER["REQUEST_METHOD"]. Om REQUEST_METHOD är POST, har formuläret skickats - och det bör valideras. Om det inte har skickats, hoppa över valideringen och visa ett tomt formulär.

Men i exemplet ovan är alla inmatningsfält valfria. Skriptet fungerar bra även om användaren inte anger någon data.

Nästa steg är att göra inmatningsfält obligatoriska och skapa felmeddelanden om det behövs.

I förra artikeln lovade jag att skriva en jämförelse av mitt eget bibliotek med andra tillgängliga lösningar, så idag ska vi titta på validering med Aura.Filter , Respect Validation , Sirius Validation och Valitron .

Låt oss föreställa oss att vi har någon form av public service under utveckling, som går ut på att registrera användare för full tillgång till alla funktioner. Registreringsformuläret kommer därför att innehålla följande fält:

1. namn. Måste innehålla exakt två ord, där det första är användarens förnamn och det andra är efternamnet.
2. logga in. Om ett värde godkänns måste det endast innehålla latinska bokstäver, bindestreck och understreck.
3. e-post. Måste innehålla en giltig e-postadress.
4. Lösenord. Måste vara installerat och inte längre än 64 tecken.
5. gick med på. En typisk kryssruta som användaren måste markera för att bekräfta sitt samtycke till användarvillkoren.

Så vi har fem fält som användaren måste fylla i för att registrera sig i vår imaginära tjänst. Låt oss föreställa oss att vi fick helt ogiltig data som indata:

Aura.Filter

Validering med Aura.Filter börjar med en filterfabrik. Vi måste skapa ett så kallat "ämnesfilter", eftersom vi kommer att validera en array, inte ett individuellt värde.

Att definiera reglerna

Som du kan se är beskrivningen av reglerna ganska enkel. Aura.Filter tillhandahåller en hel uppsättning användbara regler direkt, och några av dem användes i exemplet ovan:

1. isNotBlank-metoden. Anger att fältet inte kan vara null.
2. alnum. Denna regel tillåter endast latinska bokstäver.
3. e-post. Och så tydligt :)
4. strlenMax. Anger att fältet inte får överskrida längden som anges av det andra argumentet för metoden is.
5. ring tillbaka. Denna typ av regel liknar stängningar från Kontrolio. Det låter dig definiera en regel som en stängning. Till denna stängning skickar Aura.Filter "ämne", vår samling av data från formuläret och ett fält, i det här fallet överens .

Du kanske har märkt att jag inte specificerade two_words-regeln. Naturligtvis finns det ingen sådan regel i Aura.Filter, så vi måste skapa den. Som dokumentationen säger görs detta med en separat klass för regeln:

Det andra steget är att låta filterfabriken veta om vår nya regel. Det görs genom att skicka det första argumentet som en rad regler till filterfabriken:

Nästa steg är att meddela Aura.Filter att vi har skapat en ny regel och vill använda den. Detta görs genom att skicka en rad regler till det första fabriksargumentet:

Nu kan vår two_words-regel användas precis som vilken annan regel som helst från standardfördelningen.

Respons

Som ni minns är indata som vi validerar helt ogiltigt, eftersom varje fält innehåller ett felaktigt värde eller inte alls innehåller det. Därför antas det att vi som ett resultat av validering kommer att få fel och motsvarande meddelanden om dem.

Vi validerar med Aura.Filter enligt följande:

PÅ $meddelanden en array skrivs, så vi behöver två kapslade foreach för att visa meddelanden:

$errors) (foreach ($errors som $error) ( printf("", $error); ) ) ?>

Respektera validering

Det andra biblioteket jag använde i jämförelse är en relativt populär lösning som heter Respect Validation. Eftersom folk litar på henne tror jag att det finns något att se där.

För experimentets renhet kommer vi att använda samma datauppsättning som definierades i början när vi jämför bibliotek:

Att definiera reglerna

Precis som med Aura.Filter behöver vi vår egen valideringsregel för användarnamnet, så låt oss börja med det:

API:et för externa regler är nästan identiskt med Aura.Filter, bara metoden bekräfta() istället för magi __åberopa(). Det verkade för mig, detta API, mer enkelt och begripligt. Tja, det är närmare Kontrolio :)

Jag hittade inget omnämnande av detta i dokumentationen, men utöver själva regeln är det nödvändigt att skapa en egen typ av undantag för den. Undantagsklassens namn måste bestå av regelklassens namn och en postfix Undantag.

Äntligen kan vi validera våra uppgifter. Först skickar vi vår nya regel till valideraren så att den känner till den, så att vi kan använda den i framtiden. I Respect Validation görs detta genom att anropa metoden med() med överföringen av namnutrymmet där de icke-standardiserade reglerna finns.

Nu alla icke-standardiserade regler som finns i namnutrymmet mitt namnutrymme, kommer att "identifieras" av valideraren. Nästa steg är att beskriva de regler som krävs och utföra validering.

Lägg märke till hur vi tillämpar vår regel på attributet namn. Här har namnet på regelklassen omvandlats till namnet på valideringsmetoden. Resten av reglerna är i allmänhet intuitiva.

Separat är det värt att nämna varför vi tar med arrayen $data till föremålet. Faktum är att Respect Validation tar objekt som indata, inte arrayer. Detta bör beaktas när du utvecklar med detta bibliotek.

Respons

Till skillnad från Aura.Filter ger Respect-validatorn ett undantag när valideringen misslyckas. Och detta undantag innehåller valideringsfelmeddelanden. Därför bör exemplet som just visas skrivas så här:

Använder sig av getMessages(), kommer vi att få en platt uppsättning av alla meddelanden som valideraren samlade in under valideringsprocessen. Genom att dumpa en array får vi något sånt här:

Du kan ändra meddelandena till dina egna. Jag kanske missförstod det här biblioteket på något sätt, men den här processen verkade inte så uppenbar för mig: du måste använda metoden findMessages() på ett hanterat undantag där du definierar meddelanden inte för attribut utan för regler.

Jag vet inte vad felet är, men det finns ett par saker som jag fortfarande inte förstår. Detta är vad vi får genom att definiera reglerna på ovanstående sätt:

Som du kan se användes inte meddelandet för e-postfältet, det vanliga fanns kvar. Men budskapet bakom index 4 är det motsatta! Och detta trots att jag inte använde namnet på regeln, utan namnet på fältet. Om jag använde namnet på regeln (trueVal), skulle mitt meddelande försvinna någonstans. Kommentarer från erfarna användare av detta bibliotek är mycket välkomna.

Sirius-validering

Ok, låt oss gå vidare till nästa bibliotek och se hur det hanterar liknande uppgifter.

Att definiera reglerna

Återigen måste vi definiera en regel för användarnamnet. Vi skriver det ungefär så här:

Var uppmärksam på skillnaden i tillvägagångssätt i jämförelse med de bibliotek som redan övervägts. Vi definierar två typer av meddelanden i konstanter istället för att använda egenskaper, metoder eller regelargument.

Låt oss nu beskriva valideringslogiken:

Som du kan se är uppsättningen regler ganska enkel och läsbar. För beskrivningar använder vi namn separerade med horisontella streck. Detta tillvägagångssätt liknar det som används av Laravel och Kontrolio.

Fjärde metoden argument Lägg till() beskriver valideringsfelmeddelandet som Sirius använder om valideringen misslyckas. Varför lade vi inte till ett meddelande för vår nya regel UserNameRule?

Detta beror på att meddelandena redan är beskrivna i klasskonstanterna:

Ett annat alternativ är att använda metoden addMessage() för själva valideraren:

Observera att anpassade regler identifieras med det fullständiga namnet på deras klass, medan du i Kontrolio kan ställa in ett alias/alias.

Respons

För att utföra validering anropar vi valideringsmetoden bekräfta(), skickar data till den:

Till skillnad från Respect kommer Sirius inte att göra ett undantag, det kommer helt enkelt tillbaka falsk. Valideringsfelmeddelanden kan tas emot via valideringsmetoden getMessages(). Den returnerar fel grupperade efter attribut, så vi behöver två för varje loop för att iterera igenom felen:

Här är $message ett klassobjekt Sirius\Validation\ErrorMessage, som har en metod getTemplate(), som returnerar själva budskapet vi behöver.

Valitron

Att definiera reglerna

Den första skillnaden är att du inte behöver skapa en separat klass för att lägga till en ny regel. Du kan helt enkelt använda en stängning som ger ett booleskt resultat.

Det finns en statisk metod för att lägga till anpassade regler till Valitron addRule(), där de två första argumenten krävs och det tredje är valfritt. Jag gillade den här metoden, för här anges regelidentifieraren, logiken och felmeddelandet på ett ställe samtidigt.

Den andra skillnaden är hur reglerna tillämpas på attributen. I alla tidigare fall har vi sett att ett attribut så att säga är en primär sak.

Valitron gick åt andra hållet och satte valideringsreglerna i första hand. När du beskriver reglerna, applicerar du typ attribut på dessa regler, och inte vice versa.

Som du kan se från exemplet, i metoden regel() vi skriver först namnet på regeln, och först därefter anger vi de attribut som måste matcha denna regel. Ett mer explicit exempel är den obligatoriska regeln, som visar hur attribut "tillhör" regeln.

Valitron (som de andra lösningarna vi har tittat på) tillhandahåller standardfelmeddelanden. Om du bara använder dem kommer du att se att varje meddelande börjar med namnet på motsvarande attribut.

Valitron ersätter attributnamn i meddelandetexten även när icke-standardiserade felmeddelanden används. Det är därför vi använde metoden label() med en tom sträng för att ta bort attributnamnet.

Respons

När det gäller validering är Valitron-bibliotekets API praktiskt taget inte annorlunda än vad vi redan har sett i artikeln. För att utföra validering anropar vi valideringsmetoden bekräfta():

Valideringsfelmeddelanden kan erhållas med metoden getErrors():

Meddelandena här är grupperade efter attribut på exakt samma sätt som i Sirius Validation, förutom att det inte finns någon separat klass för meddelandet, och vi får en vanlig flerdimensionell array.

kontrollera

Och slutligen, det sista biblioteket för idag är min egen utveckling som heter Kontrolio .

Att definiera reglerna

Återigen, för femte gången kommer vi att skapa en valideringsregel för användarnamnet. Allt är relativt enkelt och standard:

Nu skapar vi en fabrik och registrerar regeln i den med metoden förlänga():

Efter att ha registrerat regeln kan vi använda den, inklusive genom namn - two_words . Låt oss skapa en validator:

Vi har beskrivit reglerna med en syntax som liknar den som används i Laravel, även om vi kunde ha använt en mer utförlig version:

Respons

Validering startas med samma metod bekräfta():

Nu kan vi få felmeddelanden med en av metoderna getErrors() eller getErrorsList(). Den första metoden tillåter mer komplexa felutdata, medan den andra returnerar en platt array. Använder sig av getErrors() vi kan skicka meddelanden så här:

$meddelanden): ?>

A med getErrorsList() du kan göra en enklare lista med meddelanden:

Resultat

I den här artikeln visade jag exempel på hur du använder följande bibliotek:

1. Aura.Filter
2. Respektera validering
3. Sirius-validering
4. Valitron
5. kontrollera

"Exempel från den verkliga världen" kan tyckas för enkelt. Jag måste hålla med, eftersom vissa funktioner i biblioteken faktiskt utelämnades i artikeln. Om du är intresserad kan du i princip själv studera deras egenskaper.

Vart och ett av biblioteken erbjuder sina egna marker, har sina egna mörka sidor, så jag tror att det är en smaksak och uppgift – att välja rätt.

Tack för att du läser. Gör rätt val.

Taggar:

• datavalidering
• php
• cykling

Godkväll allihop (snarare natt – reds anm). Idag ska vi förbättra den lite. Låt oss först lära oss hur man gör formulärvalidering i php och det gör vi vissa skyddsmanipulationer.

Så titta på koden nedan och notera följande ändringar och följande anledningar till ändringarna. Jag har markerat alla nya rader.

Ändrade namnet på formulärfälten. Du frågar - varför i helvete behöver vi det här? Och allt är enkelt, jag kommer att svara dig. Så vitt jag vet, strövar vissa spambots på webbplatser och letar efter formulär och fyller i dem baserat på namnen på dessa fält. I teorin, om de inte hittar en matchning, så går de hem, vilket är vad vi behöver. Naturligtvis, graden av detta skydd, jag tror inte att det är särskilt bra, men det kommer inte att minska från oss, och om skräpposten minskar med 1 e-post, kommer det redan att vara bra =).

Söker efter korrekt e-postadress. Linje 17 använder sig av elseif-operatören, som kommer att kontrolleras om om vi har fått ett positivt svar, det vill säga det står att mailadressen inte är tillgänglig alls, det vill säga att den inte angavs. Här använder vi funktionen preg_match, som låter dig jämföra den angivna adressen med vanligt uttryck. Om reguljära uttryck kanske jag kommer att skriva kort senare, men för nu är det värt att veta att ett reguljärt uttryck skapar ett visst mönster som vår sträng kontrolleras mot. Och om, i vårt fall, den angivna adressen inte matchar uttrycket, kommer ett fel att visas igen. Till exempel, här är ett par reguljära uttryck:
|^[-a-ne\s\.,;:\?!]+$|i- Detta reguljära uttryck låter dig bara använda det ryska alfabetet och vissa tecken som mellanslag, punkt, kommatecken, etc.
#http://[-a-z0-9_.]+[-a-z0-9_:@&?=+,.!/~*’%$]*\.(html?|php)#i- och detta uttryck låter dig kontrollera stavningen av adressen på Internet.

Därefter används else-satsen, där all vår kod för att skicka brevet redan har överförts. Du kan skapa valfritt antal valideringsregler själv, lägg bara till nya elseifs, till exempel för att kontrollera en e-postadress, så blir du nöjd.

$mailto=" [e-postskyddad]";
$charset = "windows-1251";
$subject = "Meddelandenamn";
$content = "text/html";
$status="
";
if (!empty($_POST))
{
$name = htmlspecialchars(stripslashes($_POST["imko"]));
$message = htmlspecialchars(stripslashes($_POST["tikstik" ]));
$mail = htmlspecialchars(stripslashes($_POST["posta"]));

if (tom ($_POST["posta" ]))
{
$status = "Du skrev inte in din e-post!";
}
elseif (!preg_match( "/^[e-postskyddad]+\.(2,6)$/i", $mail))
{
$status = "Du har angett en ogiltig e-post!";
}
annan
{
$headers = "MIME-version: 1.0\r\n";
$headers .= "Content-Type: ".$content." charset=".$charset."\r\n";
$headers .= "Från: \"".$name ."\"<".$mail .">\r\n";
$headers .= "Hemlig kopia: [e-postskyddad]\r\n";
$headers .= "X-Mailer: E-post från min supersajt \r\n";
$sendmessage = "

Kontakt e-post:".$mail."

Meddelande:".$meddelande."

Kontaktperson:

Mail för kommunikation:

Meddelande:

Så här kan du validera dina formulär i PHP utan att behöva ta till något annat. Nästa inlägg om ämnet formulär tror jag kommer att betraktas som formulärvalidering i jQuery. Under tiden ser jag fram emot dina kommentarer och förslag. God natt och god morgon alla =).

1. kontrollera att alla obligatoriska fält är ifyllda
2. kontrollera om e-postadressen eller URL-adressen är korrekt
3. kontrollera att resten av uppgifterna är korrekta(endast siffror eller bokstäver kan anges i inmatningsfältet, eller båda, eller kontrollera att inloggningen är unik i databasen, etc.)
4. filtrera data från skadlig kod

Som regel upprepas alla dessa kontroller och du måste skriva nästan samma kod för att validera POST-data, vilket leder till duplicering av php-kod.

För att undvika detta skrev jag en enkel klass för POST-datavalidering i PHP. Den här klassen är väldigt enkel och lätt att använda och du kan använda den i dina skript. Denna klass kallas Validator.

Jag måste genast säga att min klass liknar ett bibliotek Form_validation i kodantändare , bara lite ändrad. Därför, om du är bekant med det här biblioteket, kommer det inte att vara svårt för dig att förstå min POST-datavalideringsklass.

Det jag gillade med Form_validation-biblioteket var lättheten att ställa in fält för validering och själva valideringen. Detta var utgångspunkten för mig när jag utvecklade min egen valideringsklass.

Låt oss ta en titt på ett litet exempel på hur du använder den här klassen.

Require_once "validator.php"; $validator = new Validator(); $validator->set_rules("namn","Ditt namn",array("required" => "Fält %s krävs ","alpha" => "Fält %s får endast innehålla bokstäver ")); $validator->set_rules("email","Din e-post",array("required" => "Fält %s krävs ","valid_email" => "Fält %s måste innehålla en giltig e-postadress ")); if($validator->run())( echo "Validering lyckades"; ) else( echo $validator->get_string_errors(); )

Först inkluderar vi klassfilen validator.php till vårt manus. Skapa sedan en instans av klassen och spara objektet i en variabel $validator .
Använd sedan metoden $validator->set_rules($field, $label, $rules) ställ in fält för validering.

Denna metod tar tre parametrar:

1. $fält — Namnet på valideringsfältet (värdet på namnattributet i taggen )
2. $-etikett — valideringsfältets namn, kommer att ersättas i felmeddelanden
3. $regler är en uppsättning valideringsregler, vars nyckel är valideringsregeln och värdet är felmeddelandet för denna regel

Efter att alla fält för validering är inställda kör vi valideraren med metoden $validator->run() . Om valideringen lyckades kommer denna metod att returnera värdet SANN , annars kommer , om det finns åtminstone några fel , tillbaka FALSK .

Det finns tre metoder för att få felmeddelanden:

1. get_string_errors() - returnerar alla felmeddelanden som en sträng
2. get_array_errors() - returnerar alla meddelanden som en array, där nyckeln är namnet på fältet och värdet är beskrivningen av felet för detta fält.
3. form_error($field) - returnerar ett felmeddelande för fältet som skickats som parametern $field

Som standard är felmeddelanden insvept i en tagg . För att sätta din egen design, använd metoden set_error_delimiters($prefix, $suffix) . Till exempel så här:

$validator->set_error_delimiters("

Nu kommer felmeddelanden att packas in div med klass "fel"

Som du kan se är allt väldigt enkelt.

För att ställa in valideringsregler kan du använda metoden set_rules($fields) passera en flerdimensionell associativ array. Låt oss titta på ett exempel:

$rules = array(array("field" => "namn", "label" => "Ditt namn", "rules" => array("required" => "Fält %s krävs ", "alpha" = > "Fält %s får endast innehålla bokstäver ")), array("field" => "e-post", "label" => "Din e-post", "rules" => array("required" => "Fält % s krävs ", "valid_email" => "Fältet %s måste innehålla en giltig e-postadress "))); $validator->set_rules($rules);

Som du kan se har jag skrivit samma valideringsregler som i det första exemplet, bara som en flerdimensionell associativ array. Du kan använda någon av de metoder som passar dig bäst i en given situation.

Så vilka valideringsregler stöder denna klass?

Jag tog med mig in i den här klassen mest allmänning valideringsregler som alla möter. Här är en komplett lista över dessa regler:

De flesta av dessa regler använder filter, som blev tillgänglig i PHP 5.

Reg.ru: domäner och hosting

Den största registratorn och värdleverantören i Ryssland.

Över 2 miljoner domännamn i tjänst.

Marknadsföring, mail för domän, lösningar för företag.

Mer än 700 tusen kunder runt om i världen har redan gjort sitt val.

* För muspekaren för att pausa rullningen.

Tillbaka framåt

Validering och datarensning med PHP

Datasäkerhet är en mycket viktig punkt som ofta underskattas av både utvecklare och kunder. Sedan PHP 5.2.0 har datarensning och validering (kontroll mot vissa kriterier) blivit lättare med införandet av datafiltrering. Idag ska vi titta på hur man filtrerar, hur man använder filter och skapar några anpassade funktioner.

Introduktion

Jag har alltid känt att det är lätt att skriva PHP-kod, och det är ännu lättare att skriva dålig PHP-kod. Många open source-projekt som WordPress, Drupal, Magento har bidragit till den utbredda användningen av PHP inom webbutvecklingsområdet. Dessutom är det webbapplikationer som Facebook osv. Med en så bred användning av PHP (dynamiska webbplatser, bloggplattformar, innehållshanteringssystem, användning i e-handelsapplikationer etc.) är sannolikheten att stöta på "smutsig" information och osäkra system mycket hög. Den här handledningen kommer att visa dig några datarensnings- och valideringsmetoder med PHP. Vi kommer att fokusera på flera typer av input och hur man använder PHP-filter och användardefinierade funktioner.

Varför rensa och kolla?

I den här guiden kommer vi att fokusera på information som kommer direkt från användare, såväl som från andra externa källor. Det betyder att vi inte har någon kontroll över den information vi får. Allt vi kan göra är att kontrollera vad som kommer att göras med denna mottagna information. Nästan alla typer av hot kommer från information som överförs av användare eller annan tredje part.

Bland de viktigaste:

- XSS (Cross-Site Scripting - Cross-Site Scripting)

Detta är en kodinjektionsmetod, när ett skript injiceras på sidan på den attackerade webbplatsen från en helt annan webbplats på en annan server. Denna sårbarhet anses vara en av de mest utbredda i nätverket.

- SQL-injektion

Nästa populära sårbarhet är en annan form av kodinjektion som tillåter olika typer av skadligt beteende, inklusive obehörig åtkomst till information, modifiering av information i en databas eller annan störning av en webbapplikations normala funktion. Denna attack utförs genom att injicera en godtycklig SQL-kod i frågan, utformad för att interagera med databasen.

- CSRF/XSRF (Cross-Site Request Forgery)

Denna sårbarhet är mindre vanlig än de tidigare. Vanligtvis uppstår sådana sårbarheter när man arbetar med sessioner och cookies, och mer sällan - med dåligt kontrollerade och rensade data. CSRF kan användas för att göra förfrågningar till webbplatsen utan användarens vetskap. Ett känt sätt att implementera denna attack är att använda ett felaktigt attribut src vid bilden, vilket leder till exekvering av något manus, och inte till visning av bilden.

- Felaktig information

Felaktig information i sig är ingen "sårbarhet". Sådan information leder dock i många fall till en rad problem för både webbplatsägaren och databasadministratören. Ofta leder information som är felaktig i strukturen till funktionsfel, särskilt om webbplatsen är implementerad på amatörnivå, inte enligt standarder, samt till fel i driften av automatiserade system som förväntar sig att tydligt strukturerad data i ett visst format ska vara bearbetas.

Översättning av dialogen till bilden:

Hej, det är från din sons skola du är orolig. Vi har ett problem med datorer här.

Åh gud, slog han sönder något?

Är din sons namn verkligen Robert"); DROP TABLE-studenter;?

Åh ja vi kallar honom Lilla Bobby bord

Du förstår, vi har tappat alla rekord på årets elever. Jag hoppas att du är nöjd.

Och jag hoppas att du lär dig hur du kontrollerar informationen i databasen.

För våra syften kommer vi bara att fokusera på att använda informationssäkerhetstekniker på serversidan, så låt oss se hur termerna "sanering" och "validering" definieras i relation till PHP. Låt oss ta en titt på PHP-manualen:

"Validering används för att kontrollera om informationen som kontrolleras uppfyller vissa krav. Med FILTER_VALIDATE_EMAIL avgör vi till exempel om informationen är en giltig (dvs korrekt i strukturen) e-postadress, men ändrar inte denna data.

Rengöring innebär å andra sidan en möjlig förändring av informationen som kontrolleras, till exempel borttagning av oönskade tecken. Låt oss säga att användningen av FILTER_SANITIZE_EMAIL tar bort tecken som inte ska finnas i en e-postadress. De där. i det här fallet finns det ingen verifiering av adressens riktighet (d.v.s. validering), men medvetet olämpliga tecken raderas - inget mer."

I grund och botten, om du föreställer dig din sida som en nattklubb som alla vill gå till, handlar validering om att kontrollera om gästen finns på inbjudningslistan, sanering fungerar som en studsare som inte släpper in oönskade element i klubben. Mer eller mindre så här.

Vilka filter har jag?

Alla PHP-installationer kan inte vara identiska. Även om filter introducerades i PHP 5.2.0, har inte alla installationer samma uppsättning filter. I de flesta fall kommer alla filter vi ska prata om redan att inkluderas med PHP installerat på din server, men för att ge dig lite mer information om filter så tittar vi på vad som finns tillgängligt på din server. Källkodsfil bifogas getfilters.php, som, när den väl har installerats och körts på servern, visar en lista över alla dina filter (som informationsfilter tillgängliga via funktionen filter_var, och streaming tillgänglig via stream_filter_append)

eko"

Datafilter

Vi får först en array som innehåller en lista över alla tillgängliga filter som använder funktionen filter_list, varefter vi går igenom arrayen och visar filternamnet och dess ID.

Hur kan jag använda filtret?

PHP-filter för validering och sanering aktiveras genom att skicka en funktion filter_var minst två parametrar. Som ett exempel, låt oss tillämpa ett tydligt filter på ett heltal:

$value = "(!LANG:123abc456def"; echo filter_var($value, FILTER_SANITIZE_NUMBER_INT); !}

I det här exemplet har vi en variabel värde, som vi överför till funktionen filter_var från tillägget PHP Filters med filtret FILTER_SANITIZE_NUMBER_INT. Som ett resultat kommer vi att få:

Rensningsfiltret för heltal tar bort alla icke-heltalstecken, vilket ger oss ett "rent" heltal. I källorna kan du prova olika ingångar, och ett antal vanliga filter kommer att tillämpas på dem. I arkivet finns olika strängar som du själv kan använda som testmaterial.

Vad gör de olika filtren?

Listan nedan är inte uttömmande, men den innehåller de flesta filter som följer med en standard PHP 5.2.0+ installation.

FILTER_VALIDATE_BOOLEAN: Kontrollerar om den givna informationen är en boolesk SANT eller FALSK. Om det godkända värdet inte är av typen Boolean returneras FALSE. Skriptet nedan kommer att mata ut TRUE för variabelexemplet värde1 värde02:

$value01 = TRUE; if(filter_var($value01,FILTER_VALIDATE_BOOLEAN)) ( echo "TRUE"; ) else ( echo "FALSE"; ) echo "

" $value02 = FALSE; if(filter_var($value02,FILTER_VALIDATE_BOOLEAN)) ( echo "TRUE"; ) else ( echo "FALSE"; )

FILTER_VALIDATE_EMAIL: Kontrollerar om den skickade informationen är en giltig e-postadress vad gäller strukturen. Den kontrollerar inte om denna adress faktiskt finns, utan endast adressens giltighet, d.v.s. riktigheten av dess struktur. Skriptet nedan kommer att mata ut TRUE för variabelexemplet värde01 och FALSE för variabelexemplet värde02(eftersom den obligatoriska delen med @-tecknet saknas):

$value01 = " [e-postskyddad]"; if(filter_var($value01,FILTER_VALIDATE_EMAIL)) ( echo "TRUE"; ) else ( echo "FALSE"; ) echo "

" $value02 = "nettuts"; if(filter_var($value02,FILTER_VALIDATE_EMAIL)) ( echo "TRUE"; ) else ( echo "FALSE"; )

FILTER_VALIDATE_FLOAT: Kontrollerar om det godkända värdet är ett flyttal. Skriptet nedan kommer att mata ut TRUE för variabelexemplet värde01 och FALSE för variabelexemplet värde02(eftersom split "," är inte tillåtet i flöten):

$value01 = "1.234"; if(filter_var($value01,FILTER_VALIDATE_FLOAT)) ( echo "TRUE"; ) else ( echo "FALSE"; ) echo "

" $value02 = "1,234"; if(filter_var($value02,FILTER_VALIDATE_FLOAT)) (eko "TRUE"; ) else (eko "FALSE";)

FILTER_VALIDATE_INT: Kontrollerar om det godkända värdet är ett heltal. Skriptet nedan kommer att mata ut TRUE för variabelexemplet värde01 och FALSE för variabelexemplet värde02(decimaltal är inte heltal):

$value01 = "123456"; if(filter_var($value01,FILTER_VALIDATE_INT)) ( echo "TRUE"; ) else ( echo "FALSE"; ) echo "

" $value02 = "123.456"; if(filter_var($value02,FILTER_VALIDATE_INT)) (eko "TRUE"; ) else (eko "FALSE";)

FILTER_VALIDATE_IP: Kontrollerar om det godkända värdet är en giltig IP-adress. Den kontrollerar inte om det finns ett svar från denna adress, utan bara att det skickade värdet, genom sin struktur, är en IP-adress. Skriptet nedan kommer att mata ut TRUE för variabelexemplet värde01 och FALSE för variabelexemplet värde02:

$value01 = "192.168.0.1"; if(filter_var($value01,FILTER_VALIDATE_IP)) ( echo "TRUE"; ) else ( echo "FALSE"; ) echo "

" $value02 = "1.2.3.4.5.6.7.8.9"; if(filter_var($value02,FILTER_VALIDATE_IP)) ( echo "TRUE"; ) else ( echo "FALSE"; )

FILTER_VALIDATE_URL: Kontrollerar om det godkända värdet är en giltig URL. Det gör den inte, den kontrollerar inte att resursen är tillgänglig, bara att strukturen för URL:en följs. Skriptet nedan kommer att mata ut TRUE för variabelexemplet värde01 och FALSE för variabelexemplet värde02:

$value01 = "http://net.tutsplus.com"; if(filter_var($value01,FILTER_VALIDATE_URL)) ( echo "TRUE"; ) else ( echo "FALSE"; ) echo "

" $value02 = "nettuts"; if(filter_var($value02,FILTER_VALIDATE_URL)) ( echo "TRUE"; ) else ( echo "FALSE"; )

FILTER_SANITIZE_STRING: Som standard tar detta filter bort all felaktig eller otillåten information på en rad. Till exempel kommer det att ta bort alla HTML-taggar som eller"; echo filter_var($värde, FILTER_SANITIZE_STRING);

Detta skript tar bort taggarna och returnerar följande:

Alert("PROBLEM HÄR");

FILTER_SANITIZE_ENCODED: Många programmerare använder funktionen urlencode(). Detta filter utför i huvudsak samma funktioner. Till exempel kommer följande exempel att koda alla specialtecken och mellanslag i inmatningssträngen:

$value = "(!LANG:"; echo filter_var($value, FILTER_SANITIZE_ENCODED); !}

Skriptet kommer att koda skiljetecken, mellanslag, parenteser och returnerar följande:

%3Cscript%3Ealert%28%27TROUBLE%20HERE%27%29%3B%3C%2Fscript%3E

FILTER_SANITIZE_SPECIAL_CHARS: Detta standardfilter gör HTML-kodning av specialtecken som citattecken, et-tecken och parenteser. Eftersom demosidan inte explicit kan visa detta (eftersom de HTML-kodade specialtecknen kommer att tolkas av webbläsaren och visas), kan du se detta om du tittar på källkoden:

$value = "(!LANG:"; echo filter_var($value, FILTER_SANITIZE_SPECIAL_CHARS); !}

Specialtecken kommer att konverteras till sina HTML-enheter: