Du bör använda PHP-filtreringsfunktioner, del 2

I det föregående inlägget pratade jag om anledningarna till att använda PHP-filtreringsfunktioner är mer användbart än inte.

Kort sagt, att göra det hjälper till att ge en nivå av validering som är inbyggd i språket så att vi inte behöver skriva om något. Naturligtvis finns det varningar.

Till exempel, om du måste validera ett värde som är av icke-latinska tecken, då kommer du att behöva göra det ensam och implementera validering med kanske ett reguljärt uttryck.

Men om du använder e-postadresser, webbadresser, nummer, IP-adresser och så många fler saker, så är du i en bra position att använda något som redan finns.

Hur som helst, allt ovanstående handlar fortfarande om att filtrera variabler. Men hur är det med inputs? Det vill säga de som kommer från $_POSTeller $_GET. Det är möjligt att använda en liknande strategi med en annan funktion och annan filteruppsättning.

Men om du förstår grunderna som presenterades i det förra inlägget, kommer det här inlägget inte att vara mycket annorlunda.

PHP-filtreringsfunktioner, del 2: Ingångar

Filtrering av ingångar görs av filter_inputfunktionen. Definitionen för denna specifika funktion är:

Hämtar en specifik extern variabel efter namn och filtrerar den valfritt

PHP-manualen

Och, som nämnde förra gången, detta låter lite konstigt tills du förstår vad filtren är. Som tur var tog vi upp detta i förra inlägget. Och även om det här inlägget kommer att fokusera specifikt på POST(och mycket kortfattat GET).

Det finns dock andra filter. Och dessa inkluderar:

• INPUT_COOKIE
• INPUT_SERVER
• INPUT_ENV

Hur som helst, eftersom de två vanligaste operationerna som jag brukar se i WordPress inkluderar POSToch GET, så verkar det viktigt att ta med dessa två här.

Att använda dessa funktioner är trivialt enkelt. Anta att du har ett värde som kommer från något som användaren har angett i ett formulär och att de skickar det till servern med en POSTbegäran med en nyckel som firstname.

Koden för att verifiera den kan se ut ungefär så här:

• filter_input(INPUT_POST, 'firstname');

Vilket är lätt nog att förstå eftersom det helt enkelt tar nyckeln, filtrerar den och sedan returnerar ett värde. Och eftersom det returnerar ett värde kan vi ställa in en skyddsklausul innan vi går vidare med något mer arbete:

1if (false === filter_input(INPUT_POST, 'firstname')) {
2  return;
3}

Om allt checkar ut kan vi gå vidare och göra vad vi än behöver göra med användarinformationen. Kanske måste vi associera det med det aktuella inlägget av någon anledning:

1if (false === filter_input(INPUT_POST, 'firstname')) {
2  return;
3}
4 
5$firstname = filter_input(INPUT_POST, 'firstname');
6update_post_meta(get_the_ID(), 'acme-firstname', $firstname);
7 
8// Other code you may use...

Vidare kan du säkra information ännu mer genom att använda de olika filter som finns. Dessa skickas som en tredje parameter till filter_inputfunktionen.

Och vad sägs om GET?

Det fina med den här funktionen är att, generellt sett, gäller samma regler som de gör med POSTförutom att INPUT_POSTdu använder istället för att använda INPUT_GET.

Och sedan kan du arbeta igenom din kod hur den bäst passar ditt projekts behov.

Säkerhet, Nonces, etc.

Kom ihåg att detta inte är något som ska användas i stället för säkerhet. Detta är enbart i syfte att säkra data innan du gör något med det.

Ersätt inte verifieringen av nonce-värden bara för att du verifierar data på ett annat sätt.

Variabler och ingångar

Kom ihåg att även om dessa funktioner är väldigt lika variabler och indata är olika. Med andra ord, försök inte använda filter_varnär du arbetar med input från användaren eller webbläsaren. Använd den när du arbetar med variabler. Och på liknande sätt, använd ht e