Projektowanie klasy obiektowego systemu logowania w php

Question

Zacząłem doskonalić swoje umiejętności w zakresie OOP, rozwiązując niektóre raczej łatwiejsze problemy podczas budowania strony internetowej. Zaczęło się od systemu logowania, poszedłem za tutorialem na youtube, który pomógł mi stworzyć klasę Login, ale jak to się działo, wzbudziło wiele wątpliwości (btw. Kod ma 100 linii, więc wkleję to wklejając).

Tak więc w tej klasie logowania istnieją metody weryfikacji itp., Ale dochodzi do punktu, w którym istnieje weryfikacja sesji, która z wcześniej podanymi parameterami nie może być użyta (co najmniej w zakresie tej klasy):

$this->_username = ($this->_login)? $this->filter($_POST['username']) : $_SESSION['username']; 
    $this->_password = ($this->_login)? $this->filter($_POST['password']) : ''; 
    $this->_passmd5 = ($this->_login)? md5($this->_password) : $_SESSION['password']; 

Tak więc w tym przypadku nie mogę użyć metody verifySession(), gdy nie ma zestawu zmiennych sesji (aby odróżnić to, co powinien zobaczyć zalogowany użytkownik na stronie głównej).

Moje pytanie brzmi - czy ten projekt jest poprawny i jak powinienem zbudować resztę systemu logowania: weryfikacja loggedIn na każdej stronie i wylogowanie - czy każdy z nich powinien być w osobnej klasie (a co z metodami, które powtórzyć w konkretnej klasie, czy powinienem je zawsze dziedziczyć). Zdaję sobie sprawę, że istnieją różne podejścia do OOP, ale czy jest jakiś szczególny, który powinienem podążać jako początkujący (który pomoże mi zrozumieć o tym najlepiej).

Answer 1

"Podążyłem za tutorialem na youtube" to pierwszy problem. Tylko trzy wiersze kodu, które wkleiłeś, pokazują, że oglądany film został stworzony przez amatorskiego programistę PHP.

„Więc moje pytanie jest - jest to, że konstrukcja poprawna i jak należy budować reszty systemu logowania”

Ponieważ tylko trzy wiersze zostały opublikowane, nie wiem, czy projekt jest poprawne lub nie. Założę się, że tak nie jest.

Dobrą zasadą do tego, kiedy należy użyć obiektu, jest kod, który jest wystarczająco zaawansowany, aby wymagał więcej niż dwóch funkcji, będzie używany w wielu miejscach w aplikacji i będzie znaczny potencjał do nazywania konfliktów, jeśli kod nie jest enkapsulowany w obiekcie lub przestrzeni nazw. To nie spełnia tych kryteriów - ekran logowania i rejestracji to po jednej stronie (najwyżej) i dlatego ten kod zostanie użyty jeden raz. Nie ma powodu, aby hermetyzować tę logikę. Niko wspomniał o klasach sesji i użytkownika, które są typowymi wzorami i które są w porządku do enkapsulacji.

Jeśli chodzi o budowę systemu logowania, szybko się komplikują i są obecnie prawie specjalnością.Radzę przeczytać poniższy artykuł SO wiki:

The definitive guide to form-based website authentication

Jeśli chcesz paczkowana system, który spełnia powyższe wiki artykuł, można spojrzeć na:

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

Klient OSM robi” t obecne klasy do aplikacji - po prostu zestaw funkcji, takich jak SSO_LoggedIn(), SSO_Login(), SSO_Logout(), itp. Robienie OOP tylko ze względu na wykonanie OOP, gdy coś prostszego będzie wystarczało, jest niewłaściwym sposobem pisania oprogramowania. Czasami funkcje są lepsze. Czasami wprowadzenie kodu jest lepsze. To naprawdę zależy, a uzyskanie wglądu w to, co będzie najlepsze, wymaga wieloletniego doświadczenia.

Answer 2

Nie jestem pewien, czy naprawdę chcesz klasę "logowania". Można zrobić somehting jak ten

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(); 

Ten projekt nie jest chyba najlepszy sposób, ale może dać ci pomysł.

Answer 3

$_SESSION['password']

To nigdy nie powinno być konieczne, aby zapisać hasło (zwykły tekst?) W sesji. Powinieneś sprawdzić, czy użytkownik może się zalogować, a jeśli to robi i podaje poprawne hasło, nie przechowujesz więcej w sesji niż "jest zalogowany". Dla wygody możesz również zapisać nazwę użytkownika.

Ale hasło nie jest potrzebne po porównaniu go z tym w bazie danych.