Login-Klasse - Überlegungen zur Struktur

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Login-Klasse - Überlegungen zur Struktur

    Kurz: Sollte eine Session die Eigenschaft eines Logins sein oder sollte der Login von der Session erben?

    Lang:

    Ich schreibe gerade meine erste Login-Klasse. Für einen Login brauche ich eine Session, eine Login-Form, einen internen Bereich und eine Datenbank. Alle grundlegenden Tutorials, die ich gefunden habe, mischen das alles zusammen und heraus kommt ein funktionierendes Skript, das ich aber niemals warten oder erweitern wollen würde.

    Angefangen habe ich jetzt mit einer Session-Klasse, deren Instanzierung die beliebte Zeile session_start() am Anfang eines Skriptes ersetzt. Sie startet erstmal nur eine Session. Allerdings müssen in eine Session ja einige Variablen rein deren Werte gefiltert werden sollten, sobald sie in Kontakt mit einer Datenbank kommen.

    Der Login besteht im Allgemeinen aus Benutzername und Passwort. Dazu gehört in der Datenbank meistens noch eine Benutzer-ID. All diese Variablen sollten mit großer Sorgfalt behandelt werden, weil sie alle entweder von der Datenbank kommen oder vom Benutzer bzw demjenigen, der sich für einen Benutzer hält.

    Was mir Kopfzerbrechen bereitet, ist die Verbindung von Session und Login. Meine konkrete Frage: Sollte der Login von der Session erben (weil er sie erweitert und zu den "Gast"-Rechten und -Funktionen noch "Benutzer"-Rechte und Funktionen kommen) oder sollte die Session eine Eigenschaft der Login-Klasse sein, weil der Login die Session nur "benutzt" (weil das die vielzitierte "Zwiebelschale" um Server und Datenbank mehr repräsentiert)?

    Abgesehen von den (eingeklammerten) Pros habe ich keine weiteren Argumente für oder wider das eine oder das andere finden können. Ich versuche, mir vorher die bessere Struktur rauszupicken, um dann nicht alles umschreiben zu müssen.

    mfg,

    Buffi

  • #2
    Ein Login kann zunächst einmal überall passieren. Deshalb solltest du eine austauschbare Komponente benutzen.
    z.B. kann ein Login ganz normal über ein Formular auf einer Webseite kommen, aber auch per Zugriff auf einen Webservice.

    Als praktisch hat sich mir ein User-Objekt erwiesen. Im Normalfall legt man das in der Session ab (dafür beerbt man dann seine User-klasse mit einer User_Session-Klasse). Die Klasse hat einen Konstruktor der den state des Objekts ändert. Hier sollte man als Parameter die Userid übergeben. Damit ist die Userklasse schon sehr nützlich. Man kann anhand des Objekts feststellen, ob der Benutzer eingeloggt ist und seine ID in allen Datenbankabfragen benutzen.
    Will man aber noch mehr Details oder die Einstellungen des Benutzers haben, kann man die Klasse wieder erweitern. Diese Details würden dann direkt in der Klasse erledigt werden.
    Im Destruktor speichert sich die Klasse wieder mit aktuellem state in der Session. Im ohne Parameter aufgerufenen Konstruktor könnte sie diesen state dann auch abfragen.

    Genug Denkhilfe

    Kommentar


    • #3
      Vielen Dank schonmal für diesen Hinweis! Er hat mir doch einige Aspekte, was das Schreiben des Codes anbelangt, vor Augen gehalten:

      - ich komme um $login->session->irgendeinefunktion() oder andere ausufernde Ausdrücke herum

      - ich kann die user-Klasse auch noch in andere Richtungen erweitern, um zum Beispiel administrative Funktionen zu implementieren (denke da an Benutzergruppen)

      - der Code zum Beginnen und Beenden einer Seite wird nicht groß (zumindest nicht durch das Einloggen)

      Hat jemand noch Argumente, die in eine andere Richtung gehen?
      Zuletzt geändert von Donbuffi; 30.06.2007, 12:52.

      Kommentar


      • #4
        Und da ist die Klasse fertig!

        Ich benutze aber nicht den Konstruktor zum laden der Daten aus der Session, sondern __wakeup(). Darin kann die Klasse direkt prüfen, ob es neue $_POST Daten für einen login gibt (falls der Benutzer noch nicht eingeloggt war). Der Konstruktor probiert nur, über Cookies einzuloggen. Vielleicht kann ich __sleep() ja auch noch sinnvoll einbauen, dann habe ich noch was gemacht, was ich vorher nie beachtet habe...

        Vielen Dank, die Denkhilfe war genau richtig

        Kommentar


        • #5
          Naja, original OOP ist $_POST in einer Klasse aber nicht...
          Da macht es ggf. mehr Sinn eine abstrakte Unterklasse Login zu gestalten und dazu eine weitere abgeleitete Klasse WebLogin und nur in der Klasse WebLogin wird auf $_POST zugegriffen - oder auch durch Aggregation eine weitere Klasse ins Spiel zu bringen, die die ggf. vorhandenen Daten der Autorisation in die eigentliche Login-Klasse bringen, und welche sich durch Polymorphie durch andere Daten-Quellen ersetzen lässt~
          Sind natürlich nur theoretische Überlegungen, in einer Umgebung wo es auf Performance ankommt sollte man da nicht so genau hinschauen~

          Ein netter Guide zum übersichtlichen Schreiben von PHP/MySQL-Code!

          bei Klammersetzung bevorzuge ich jedoch die JavaCoding-Standards
          Wie man Fragen richtig stellt

          Kommentar


          • #6
            Ja das stimmt, $_POST in einer Klasse ist nicht wirklich OOP. login abstrakt zu machen, kommt der Philosophie zwar nach, aber meine Aussichten für die Zukunft beinhalten keine Loginarten außer denen aus Formularen - ich studiere Maschinenbau...

            Für meinen konkreten Fall bedeutet die $_POST-Sache nur, dass ich eine Schleife aus einer Klassenmethode nehme und dafür dann vor ihren Aufruf schreibe. Nicht viel Aufwand, bringt mir für die Funktion nix, aber der Aufwand ist vertretbar.

            Kommentar

            Lädt...
            X