Aastaid tagasi kirjutasin postituse, milles jagasin avalikku funktsiooni, et teha kindlaks, kas kasutajal on õigusi salvestada teavet WordPressi andmebaasi. Algsesse sisu kogu oma vananenud hiilguses (koos soliidsete kommentaaridega) näete siin (see on isegi viis aastat vana – vau).
Nagu iga programmeerimisega seotud puhul, läheb aeg, asjad viimistletakse ja asjad [loodetavasti] lähevad paremaks kui varem.
Kuigi ma kasutan ja soovitan endiselt funktsiooni user_can_save (või userCanSave) varianti, arvan ka, et on oluline läbida päringu kontrollimise protsessi eraldamise protsess.
Nii et nüüd ei ole vaja ainult kindlaks teha, kas kasutajal on õigused, vaid ka kliendilt tuleva turbeteabe kontrollimine – olgu see siis serverisse tagasipostituse või Ajaxi kaudu tehtud päringu kaudu – ja seda heade programmeerimistehnikate abil, mis ühtlustavad. nii WordPressi kui PHP-ga.
Selguse huvides on see rohkem WordPressi vormi turvaline esitamine suvandite lehelt või seadete lehelt, mitte näiteks mallilt pärinev vorm. See on teine postitus teiseks korraks.
Siiski on palju inimesi, kes töötavad WordPressis rakenduste loomise kallal ja mis nõuavad järgmist.
Turvaline WordPressi vormi esitamine
Selles postituses ei hakka ma tegelema üksikasjadega, et teha kindlaks, kas miski on automaatne salvestamine või postituse läbivaatamine.
Siiski käsitlen ma sissetuleva teabe valideerimise eest vastutava funktsiooni võtmise protsessi, kasutades selleks kaasaegset lähenemist, kasutades objektorienteeritud tavasid ja nii WordPressi API-sid kui ka PHP funktsioone.
1 Alustades üldisest tasemest
Põhitasandilt oletame, et on olemas baasklass, millest on ka teisi alamklasse, mis seda funktsiooni võimendavad. See ütleb meile, et peame kasutama kaitstud nähtavuse modifikaatorit.
Teame ka, et tegeleme WordPressi nonce-väärtuse ja sellega seotud toiminguga. See tähendab, et funktsiooni allkiri näeb välja umbes selline :
2 Desinfitseerige andmed, veenduge, et puuduvad
Mis puudutab kõike, mis serverisse postitatakse, siis teame, et peame kontrollima, kas andmed on seatud, ja kui jah, siis peame teabe desinfitseerima.
See tähendab, et vajame järgmisi funktsioone:
Ja me teame ka, et peame kontrollima nonce’i, seega vajame ka faili wp_verify_nonce.
3 Töökorras esimene läbimine
Selle funktsiooni toimiv esimene läbimine võib välja näha umbes selline:
Aga mis siis, kui keegi jagab andmeid, millele on saadetud POST – päring (võrreldes GET – päringuga)? Seejärel võiksime funktsiooni muuta nii, et see näeks välja umbes selline:
Ja sellest piisaks. Kuid kui me tõesti tahame, et antud funktsioon oleks võimalikult puhas, võiksime selle veelgi jagada.
4 Funktsioon igaks otstarbeks
Arvestades ülaltoodud koodi, teame, et peame käsitlema nii GET-i kui ka POST-i päringuid. PHP pakub funktsiooni filter_input, mis on kasulik, hõlpsamini loetav (see on subjektiivne), kuid läbib ka mitmeid koodikvaliteedi kontrolle.
Lisaks saame kasutada lihtsat tehasepõhist funktsiooni, et eraldada loogika järgmisteks funktsioonideks:
Esiteks peame kirjutama kaks eraldi funktsiooni – üks POST-päringu jaoks:
Ja üks GET-taotluse jaoks:
Seejärel saame selle algses funktsioonis kokku siduda järgmiselt:
Sissetulevate taotluste puhas haldamine
Võib-olla tundub see keeruline viis lihtsa lahenduse käsitlemiseks, arvestades esialgset jagatud koodikomplekti.
See on kindlasti võimalik, eriti kui olete ajapiirangute all või ei hooli nii palju asjade jagamisest võimalikult väikesteks aatomiteks (või isegi testitavateks) komponentideks.
Kuid kui soovite kirjutada objektorienteeritud koodi suurima täpsusega, võib see protsess aidata just seda.