Design di classe del sistema di login orientato agli oggetti in php

Question

Ho iniziato a migliorare le mie competenze OOP, risolvendo alcuni problemi piuttosto semplici, quando si costruisce un sito web. Quindi è iniziato con un sistema di login, ho seguito un tutorial su youtube, che mi ha aiutato a creare una classe di login, ma mentre andava avanti, ha sollevato molti dubbi (btw. Il codice è di 100 righe quindi passerò sopra incollandolo).

Quindi, in questa classe di accesso, ci sono metodi di verifica, ecc, ma si tratta di un punto in cui non c'è la verifica della sessione, che con la prima data parameteres in costrutto, non può essere utilizzato (almeno in questo ambito di classe):

Quindi in quel caso non posso usare il metodo verifySession(), quando non ci sono variabili di sessione impostate (per distinguere ciò che l'utente registrato dovrebbe vedere sulla pagina principale per esempio).

Quindi la mia domanda è - è che una corretta progettazione, e come dovrei costruire resto del sistema di login: verifica loggedin in ogni pagina e Logout - dovrebbe ognuno di loro in classe separata (e che dire di metodi, che ripetere in particolare classe, dovrei sempre ereditarli). Mi rendo conto che ci sono diversi approcci all'OOP, ma c'è qualche particolare, che dovrei seguire come un principiante (che mi aiuterà a capire oop al meglio di esso).

Answer 1

"Ho seguito un tutorial su youtube" è il primo problema. Solo le tre righe di codice incollate rivelano che il video che hai guardato è stato creato da uno sviluppatore PHP amatoriale.

"Quindi la mia domanda è - è che una corretta progettazione, e come dovrei costruire resto del sistema di login"

Poiché solo tre righe sono state inviate, non so se il disegno è corretto o no Scommetto che non è però.

Una buona regola pratica per quando utilizzare un oggetto è quando il codice è sufficientemente avanzato da richiedere più di due funzioni, verrà utilizzato in più posizioni nell'applicazione e ci sarà un potenziale significativo per i conflitti di denominazione se il codice non è incapsulato in un oggetto o spazio dei nomi. Questo non soddisfa questi criteri: una schermata di login e di registrazione ha una pagina ciascuno (al massimo) e quindi il codice verrà utilizzato una volta. Non c'è motivo per incapsulare quella logica. Niko ha menzionato le classi Session e User, che sono modelli comuni e che possono essere incapsulate.

Per quanto riguarda la creazione di un sistema di accesso, si complicano rapidamente e sono quasi una specializzazione in questi giorni.Mi raccomando di leggere il seguente articolo SO wiki:

The definitive guide to form-based website authentication

Se si vuole un sistema preconfezionato che segue l'articolo wiki sopra, si può guardare:

http://barebonescms.com/documentation/sso/

Il client SSO doesn' t presentare classi all'applicazione - solo un insieme di funzioni come SSO_LoggedIn(), SSO_Login(), SSO_Logout(), ecc. Fare OOP solo per fare OOP quando qualcosa di più semplice sarà sufficiente per scrivere software. A volte le funzioni sono migliori. A volte è meglio inserire il codice. Dipende davvero e ci vogliono anni di esperienza per avere un'idea di quale sarà l'approccio migliore.

Answer 2

Non sono sicuro che tu voglia veramente una classe di "accesso". Si potrebbe fare somehting come questo

class User 
{ 
    private $username; 
    private $password; 

    public function __construct($username) 
    { 
    //load this user object here 
    } 

    private function hashPassword($password) 
    { 
     ///Dont do this has the hash, but im just keeping it simple 
     return md5($password . 'a}{!@#' . $this->username); 

    } 

    public function authenticate ($password) 
    { 
     return $this->hashPassword($password) == $this->password; 
    } 

} 

login.php

$user = new User($_POST['username']); 
if($user->authenticate($_POST['password'])) 
{ 
//do session initilization here (can be a class, or whatever) 
Session::createUserSession($user) 
} 
else 
echo 'bad login'; 

logout.php

Session::destroyUserSession(); 

Questo disegno non è probabilmente il modo migliore, ma può dare un'idea.

Answer 3

$_SESSION['password']

Non dovrebbe mai essere necessario memorizzare una password (testo normale?) In una sessione. Si dovrebbe verificare se un utente è autorizzato ad accedere e se lo fa e fornisce la password corretta, non si memorizza più nella sessione di "è loggato". Per comodità puoi anche memorizzare un nome utente di id utente.

Ma una password non è necessaria dopo averla confrontata con quella nel database.