Che cos'è un modo "OO carino" per gestire sessioni e autenticazione?

Tendo ad accoppiare l'autenticazione con l'autorizzazione, e non con le sessioni:

• Gli utenti possono accedere al sito e non accedere mai. Avranno comunque una sessione
• Gli utenti possono accedere al sito, accedere una volta e non disconnettersi mai. La sessione dovrebbe ancora scadere una volta che se ne sono andati.
• Gli utenti possono intraprendere azioni che richiedono un'escalation temporanea dell'autorizzazione (ad esempio, l'aggiornamento del loro indirizzo o la visualizzazione / modifica dei dati della carta di credito). Dovrebbero probabilmente accedere di nuovo per questo tipo di attività
• Dal punto di vista della sicurezza, è meglio autorizzare (e quindi autenticare) a livello di transazione piuttosto che a livello di sessione. Ad esempio, è possibile autenticarsi per ottenere il permesso di caricare alcune delle informazioni degli utenti nella sessione e poi di nuovo quando l'utente desidera modificare le informazioni. In questo modo, se qualcuno si avvicina al computer mentre l'utente non guarda, il tuo sito fa ancora la cosa giusta

Il controllo della sessione rientra nella sicurezza, che è generalmente considerata una delle aree più proficue per applicare i principi AOP piuttosto che quelli OOP. Vale a dire, le considerazioni sulla sicurezza tendono ad essere più un aspetto o una preoccupazione trasversale rispetto alla logica principale dell'applicazione. Detto questo, AOP probabilmente sarà più di una distrazione a questo punto, quindi atteniamoci a OOP.

Una delle promesse di OOP è che otterrai un codice che modella da vicino il tuo dominio problematico. Allora, cosa abbiamo qui? Utenti che ti inviano richieste, appartenenti a sessioni. Come inizio è possibile creare queste classi e provare ad immaginare le relazioni (insieme con l'assegnazione della molteplicità) tra di loro. Un modo provato e collaudato per risolvere questo problema è quello di elaborare schede CRC per ciascuna delle tue classi e immaginare le "conversazioni" che avrebbero avuto l'una con l'altra, come ad esempio un controller MVC che richiede la richiesta, sta servendo a quale sessione appartiene ea quale utente è associato.

Ecco da dove viene l'angolo di aspetto della sicurezza: il codice di sicurezza non si preoccupa veramente della logica dell'applicazione, semplicemente fa le stesse cose più e più volte. Ad esempio, se arriva una Richiesta che non è associata a una Sessione, visualizza una pagina di accesso. Alcuni framework OO chiamano questi interceptor, in termini di AOP sarebbe un aspetto - si ottiene l'idea.

Ovviamente l'applicazione potrebbe utilizzare un modello di sicurezza completamente diverso: questo è solo un esempio. Ciò che lo rende OOP è il modo in cui modella e incapsula le entità con cui hai a che fare.

Vorrei scegliere Sessioni basate su database (ad esempio memorizzare tutti i dati di sessione in un database, non il server) e racchiudere le funzioni di gestione della sessione in una classe di sessione. In una sintassi OO generica che potrebbe essere:

class Session{
    public open(name);
    public close();
    public read(var);
    public write(var, value);
    public destroy();
}

Visto che stai usando PHP, fai riferimento a session_set_save_handler e passalo il seguente.

$session = new Session();
session_set_save_handler(
    array($session,'open'),
    array($session,'close'),
    array($session,'read'),
    array($session,'write'),
    array($session,'destroy'),
    array($session,'collect')
);

Devi implementare il metodo del garbage collector e verificare il comportamento corretto per ciascuno dei tuoi metodi di gestione, ma questa sarebbe l'idea generale. Potresti anche dimenticarti di utilizzare le funzioni di sessione PHP e sostituirle con il tuo framework, ma preferirei integrare la mia classe con le funzionalità native.