Säker WordPress-formulärinlämning
För flera år sedan skrev jag ett inlägg där jag delade en offentlig funktion för att avgöra om användaren hade behörighet att spara information i WordPress-databasen. Du kan se den ursprungliga kärnan i all sin åldrade härlighet (tillsammans med de solida kommentarerna) här (det är fem år gammalt, till och med – wow).
Som med allt relaterat till programmering går tiden, saker förfinas och saker blir [förhoppningsvis] bättre än de var tidigare.
Även om jag fortfarande använder och rekommenderar en variant av funktionen user_can_save (eller userCanSave ), tycker jag också att det är viktigt att gå igenom processen för att separera processen för att verifiera begäran.
Så nu handlar det inte bara om att avgöra om användaren har behörigheter, utan det handlar om att verifiera säkerhetsinformationen som kommer från klienten – vare sig det är via ett inlägg tillbaka till servern eller en förfrågan gjord via Ajax – och att göra det med hjälp av bra programmeringstekniker som passar ihop både med WordPress och med PHP.
För att vara tydlig handlar det här mer om säker inlämning av WordPress-formulär från en alternativsida eller en inställningssida än om det till exempel är ett formulär som kommer från en mall. Det är ett annat inlägg för en annan gång.
Men ändå är vi många som jobbar med att bygga applikationer på WordPress och som kräver följande.
Säker WordPress-formulärinlämning
I det här inlägget tänker jag inte bry mig om att gå igenom detaljerna för att avgöra om något är en autospara eller en postrevision .
Jag kommer dock att gå igenom processen att ta en funktion som är ansvarig för att validera inkommande information och göra det med ett modernt tillvägagångssätt med hjälp av objektorienterade metoder och både WordPress API:er och PHP-funktioner.
1 Börjar på en allmän nivå
Från grundnivån, låt oss anta att det finns en basklass från vilken det finns andra underklasser som utnyttjar denna funktion. Detta talar om för oss att vi måste använda den skyddade synlighetsmodifieraren.
Vi vet också att vi kommer att ha att göra med ett WordPress nonce-värde och en relaterad åtgärd. Detta betyder att funktionens signatur kommer att se ut ungefär så här :
2 Rensa data, verifiera nonce
Som per allt som läggs upp på servern vet vi att vi kommer att behöva verifiera att data är inställda och i så fall kommer vi att behöva sanera informationen.
Det betyder att vi kommer att behöva följande funktioner:
Och vi vet också att vi kommer att behöva verifiera nonce, så vi kommer också att behöva wp_verify_nonce.
3 A Working First Pass
Ett fungerande första pass av den här funktionen kan se ut ungefär så här:
Men vad händer om någon delar data som har skickat en POST – begäran (mot en GET )-begäran? Sedan kan vi ändra funktionen så att den ser ut så här:
Och detta skulle vara tillräckligt. Men om vi verkligen vill att en given funktion ska vara så ren som möjligt, så skulle vi kunna bryta upp detta ytterligare.
4 En funktion för varje ändamål
Med tanke på koden ovan vet vi att vi måste hantera både GET-förfrågningar och POST-förfrågningar. PHP erbjuder en filter_input- funktion som är användbar, lättare att läsa (ja, detta är subjektivt), men som också klarar flera kodkvalitetsinspektioner.
Dessutom kan vi använda en enkel fabriksliknande funktion för att separera logiken till att separera funktioner så här:
Först måste vi skriva två separata funktioner – en för en POST-begäran:
Och en för en GET-förfrågan:
Sedan kan vi knyta ihop det i den ursprungliga funktionen så här:
Hantera inkommande förfrågningar rent
Kanske ser detta ut som ett komplicerat sätt att hantera en enkel lösning med tanke på den första uppsättningen kod som delades.
Det är säkert möjligt, särskilt om du är under tidsbegränsning eller inte bryr dig så mycket om att bryta upp saker i minsta möjliga atomära (eller till och med testbara) komponenter.
Men om du funderar på att skriva objektorienterad kod med högsta precision, kanske den här processen hjälper till med just det.