Anni fa, ho scritto un post in cui condividevo una funzione pubblica per determinare se l’utente disponeva delle autorizzazioni per salvare le informazioni nel database di WordPress. Puoi vedere l’essenza originale in tutta la sua antica gloria (insieme ai commenti solidi) qui (ha anche cinque anni, wow).
Come per qualsiasi cosa relativa alla programmazione, il tempo passa, le cose si perfezionano e [si spera] le cose migliorino di prima.
Sebbene io continui a utilizzare e raccomandare una variante della funzione user_can_save (o userCanSave ), penso anche che sia importante seguire il processo di separazione del processo di verifica della richiesta.
Quindi ora non si tratta solo di determinare se l’utente ha i permessi, ma si tratta di verificare le informazioni di sicurezza provenienti dal client, sia tramite un post sul server o una richiesta effettuata tramite Ajax, e farlo utilizzando buone tecniche di programmazione che si allineano sia con WordPress che con PHP.
Per essere chiari, si tratta più di un invio sicuro di moduli WordPress da una pagina delle opzioni o da una pagina delle impostazioni che, ad esempio, un modulo proveniente da un modello. Questo è un altro post per un’altra volta.
Tuttavia, ci sono molti di noi che lavorano alla creazione di applicazioni su WordPress e ciò richiede quanto segue.
Invio sicuro del modulo WordPress
In questo post, non mi preoccuperò di esaminare i dettagli per determinare se qualcosa è un salvataggio automatico o una revisione del post.
Tuttavia, illustrerò il processo di assunzione di una funzione responsabile della convalida delle informazioni in entrata e di farlo utilizzando un approccio moderno utilizzando pratiche orientate agli oggetti e sia le API di WordPress che le funzioni PHP.
1 A partire da un livello generico
Dal livello di base, supponiamo che esista una classe base da cui ci sono altre sottoclassi che sfruttano questa funzione. Questo ci dice che dobbiamo usare il modificatore di visibilità protetta.
Sappiamo anche che avremo a che fare con un valore nonce di WordPress e un’azione correlata. Ciò significa che la firma della funzione sarà simile a questa :
2 Sanifica i dati, verifica il nonce
Come per tutto ciò che viene pubblicato sul server, sappiamo che dovremo verificare che i dati siano impostati e, in tal caso, dovremo disinfettare le informazioni.
Ciò significa che avremo bisogno delle seguenti funzioni:
E sappiamo anche che avremo bisogno di verificare il nonce, quindi avremo anche bisogno di wp_verify_nonce.
3 Un primo passaggio di lavoro
Un primo passaggio funzionante di questa funzione potrebbe assomigliare a questo:
Ma cosa succede se qualcuno condivide i dati che hanno inviato una richiesta POST (rispetto a una richiesta GET )? Quindi potremmo modificare la funzione in modo che assomigli a qualcosa del genere:
E questo sarebbe sufficiente. Ma se vogliamo davvero che una determinata funzione sia il più pura possibile, allora potremmo suddividerla ulteriormente.
4 Una funzione per ogni scopo
Dato il codice sopra, sappiamo che dobbiamo gestire sia le richieste GET che le richieste POST. PHP offre una funzione filter_input che è utile, più facile da leggere (beh, questo è soggettivo), ma supera anche diversi controlli sulla qualità del codice.
Inoltre, possiamo usare una semplice funzione di fabbrica per separare la logica in funzioni separate come questa:
Innanzitutto, dobbiamo scrivere due funzioni separate: una per una richiesta POST:
E uno per una richiesta GET:
Quindi possiamo legarlo insieme nella funzione originale in questo modo:
Gestire in modo pulito le richieste in arrivo
Forse questo sembra un modo complicato per gestire una soluzione semplice dato il set iniziale di codice condiviso.
Questo è certamente possibile soprattutto se sei nei limiti del tempo o non ti interessa tanto rompere le cose nei più piccoli componenti atomici (o anche testabili) possibili.
Ma se stai cercando di scrivere codice orientato agli oggetti con il massimo grado di precisione, forse questo processo ti aiuterà esattamente in questo.