nicht angemeldet
Moin!
- Deine Klasse sollte allein die Aufgabe haben, über die Korrektheit von angegebenen User-Authentifizierungsdaten zu entscheiden. Sie hat aber zusätzlich auch noch eine DB-Connection intern eingebaut. Sowas ist schlechte Abstraktion - was machst du, wenn andere Teile deines Codes auch auf eine Datenbank zugreifen wollen?
Das mit der DB-Connection werd ich in eine andere Klasse packen bzw. hab ich eigentlich schon eine die ich so verwende.
Was meinst du genau mit "sollte allein die Aufgabe haben, über die Korrektheit zu entscheiden" ?
Eben genau das: Die Login-Klasse entscheidet (durch DB-Abfrage mithilfe eines ANDEREN Objekts), ob jemand dem System mit Username + Passwort bekannt ist, oder nicht. Und nur genau das, nicht mehr. Also insbesondere keine DB-Connection-Herstellung.
- session_unset() ist uralt-ekliger PHP 4.0-Session-Krams und gehört, gemeinsam mit session_register(), entsorgt. Ich bin mir auch nicht sicher, dass du weißt, was session_destroy() genau macht. Es ist ebenfalls überflüssig, die relevanten Lösch-Vorgänge löst man heutzutage mit entsprechenden Aktionen auf $_SESSION aus.
Soll ich da einfach jeden Wert von $_SESSION löschen?
$_SESSION = array(); - fertig.
Geht von der irrtümlichen Annahme weg, dass das Existieren einer Session irgendeine Aussage hinsichtlich des Login-Zustands haben würde. Sessions existieren per (vernünftiger) Definition ewig, werden aber eventuell bei zu langer Nichtbenutzung von der Garbage-Collection mal weggeschmissen. Das Session-Handling übernimmt aber komplett PHP.
Dort hinein setzt man sein Login-Handling. Eine brandneue Session enthält keinerlei Infos, also muss man offensichtlich den User erstmal nach seinen Login-Infos fragen. Aber auch eine zu lange nicht benutzte Session, die noch existiert, enthält keine brauchbaren Infos mehr: Der User sollte nach zu langer Zeit der Inaktivität als ausgeloggt betrachtet werden und sich neu anmelden müssen. Dieser Effekt darf aber keinesfalls durch die Garbage-Collection oder ein ungültig gewordenes, weil zeitlich ausgelaufenes Session-Cookie erzeugt werden, denn sowas ist userseitig sehr leicht zu manipulieren, bzw. serverseitig einfach zu unzuverlässig realisiert (das Löschen unbenutzter Sessions geschieht nur mit einer Wahrscheinlichkeit bei einem Session-Skriptaufruf - Server mit nur wenigen Besuchern räumen Sessions möglicherweise tagelang nicht weg).
- Der Zugriff auf superglobale Variablen innerhalb der Klasse ist hinsichtlich Wiederverwendbarkeit und Kapselung ebenfalls kritisch zu betrachten. Die superglobalen Variablen sind für manchen prozeduralen Code eine gute Erfindung gewesen, letztendlich aber sind es ganz normale globale Variablen - und globale Variable sind böse und sollten unbedingt vermieden werden. Auch wenn sie $_SESSION, $_COOKIE oder $_GET heißen.
Was meinst du hier genau?
Wenn du in deiner Klasse z.B. auf $_COOKIE mit bestimmten Parametern fix zugreifst, dann verbindest du deine Klasse unwiderruflich mit der Tatsache, dass a) immer Cookies genutzt werden und b) auch die Namen der Cookies immer gleichbleiben. Der Einsatz der Klasse in einem anderen Projekt wird dadurch behindert. Dabei kommt es zum korrekten Funktionieren der Prüfung von Username und Passwort bzw. dem Prüfen der Existenz einer Session nur drauf an, dass entsprechende Variablen, die als Parameter an die Methoden übergeben werden, die richtigen Inhalte haben. Die Auswahl, in welchen Request-Variablen wie $_COOKIE diese Info drinsteht, ist Aufgabe des umgebenden Programms, der die Login-Klasse aufruft.
- Sven Rautenberg