Lavorare con i transitori e l’autenticazione di WordPress
Proseguendo con il contenuto del post precedente, è importante considerare anche l’uso dei transitori e l’autenticazione.
Perché esistono scenari in cui gli utenti vengono autenticati su un sito (si pensi a un’area riservata ai membri di un sito) e/o non vengono autenticati sul sito (come i visitatori del sito).
Questi tipi di situazioni sono presenti sia sui blog che su altri siti e applicazioni web su tutta la linea.
Transitori e autenticazione di WordPress
Come potremmo memorizzare le informazioni sugli utenti per quegli utenti? Fortunatamente, PHP ci fornisce alcune funzionalità che ci danno la possibilità di farlo senza la necessità di API di WordPress.
In definitiva, l’obiettivo che miriamo a raggiungere è serializzare i dati temporanei utilizzando una chiave che utilizza l’ID di un utente autenticato o di un utente non autenticato.
Ed ecco come fare ciascuno di questi.
L’API di WordPress
Supponendo che un utente sia autenticato con WordPress, possiamo utilizzare la funzione get_current_user_id. È anche semplice.
Dal codice di riferimento:
Ottieni l’ID dell’utente corrente
Possiamo quindi utilizzare quella funzione nel costruttore per impostare una proprietà che memorizza l’ID dell’utente. E mostrerò il codice per quello momentaneamente, ma che dire della situazione in cui un utente non è connesso?
L’API PHP
Quando si tratta di archiviare informazioni per utenti che non sono autenticati, abbiamo comunque bisogno di un modo per identificarli. Questo può essere fatto in vari modi usando vari valori mantenuti da PHP da aggiungere alla chiave transitoria.
Ricorda, la chiave deve essere unica e, purché sia unica per l’utente sul sito, dovrebbe essere valida.
Due funzioni offerte da PHP sono:
Per quanto riguarda il secondo, non funzionerà utilizzando IIS o qualsiasi server basato su Windows. Ma lo sto menzionando qui come un’altra alternativa per gli host basati su * nix (poiché così tanti lo sono, specialmente per quanto riguarda WordPress).
La funzione get_current_user è abbastanza chiara:
Ottiene il nome del proprietario dello script PHP corrente
C’è anche qualcos’altro da notare nel manuale. Afferma esplicitamente questo "[restituisce] il nome del proprietario dell’attuale script PHP." E lo affronterò prima della fine del post.
Inoltre, get_current_user potrebbe anche non essere quello che stai cercando a seconda di come è configurato il server e quale utente è il "proprietario" dello script PHP in esecuzione sul server.
Ma basti dire che per questo esempio funziona. Ed ecco perché: il punto che sto cercando di dimostrare è come utilizzare valori che sono unici per un visitatore che non è autenticato su un sito per generare una chiave da cui possiamo estrarre informazioni.
Il modo in cui viene generata la chiave è secondario rispetto al codice effettivo.
Combinando Tutto Insieme
Quindi, che aspetto ha il codice se vogliamo sfruttare le funzioni di cui sopra? Cioè se manteniamo una proprietà che contiene l’ID dell’utente e quindi lo fa sia per gli utenti autenticati che per quelli non autenticati?
E questo ti darà la funzionalità necessaria per creare un ID utente univoco sia per gli utenti autenticati che per gli utenti non autenticati.
E le chiavi transitorie?
Sì, parte del punto di cui stiamo discutendo è anche la creazione di chiavi transitorie uniche.
Per fare ciò, ho trovato abbastanza semplice concatenare l’ID utente che abbiamo generato sopra e aggiungerlo alla chiave utilizzata durante la serializzazione di un transitorio.
Quindi, con il valore restituito da questa funzione, possiamo usarlo per salvare i dati come transitori utilizzando chiavi univoche.
Ancora altre opzioni
Come accennato, il semplice utilizzo delle funzionalità integrate in PHP potrebbe non essere la strada giusta da percorrere. Ma ciò non significa che non ci siano altri valori che forniscono un valore unico a ciò di cui hai bisogno.
In casi del genere, è importante identificare come si desidera identificare l’utente, quale sistema operativo sta utilizzando e quale account utente possiede l’applicazione.
Se ciò non fornisce un’impostazione sufficientemente unica (ed è molto probabile che non lo sia in determinate condizioni), il principio si applica comunque: dovrai solo sostituire la chiamata funzionale get_current_user() in qualcosa che funzioni meglio per voi.