php-resource



Zurück   PHP-Scripte PHP-Tutorials PHP-Jobs und vieles mehr > Entwicklung > PHP Developer Forum
 

Login

 
eingeloggt bleiben
star Jetzt registrieren   star Passwort vergessen
 

 

 


PHP Developer Forum Hier habt ihr die Möglichkeit, eure Skriptprobleme mit anderen Anwendern zu diskutieren. Seid so fair und beantwortet auch Fragen von anderen Anwendern. Dieses Forum ist sowohl für ANFÄNGER als auch für PHP-Profis! Fragen zu Laravel, YII oder anderen PHP-Frameworks.

Antwort
 
LinkBack Themen-Optionen Thema bewerten
  #1 (permalink)  
Alt 29-06-2007, 17:32
Donbuffi
 Newbie
Links : Onlinestatus : Donbuffi ist offline
Registriert seit: Jan 2007
Beiträge: 8
Donbuffi ist zur Zeit noch ein unbeschriebenes Blatt
Standard 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
Mit Zitat antworten
  #2 (permalink)  
Alt 29-06-2007, 21:38
rythms
 Junior Member
Links : Onlinestatus : rythms ist offline
Registriert seit: Jun 2003
Beiträge: 219
rythms ist zur Zeit noch ein unbeschriebenes Blatt
Standard

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
Mit Zitat antworten
  #3 (permalink)  
Alt 30-06-2007, 02:24
Donbuffi
 Newbie
Links : Onlinestatus : Donbuffi ist offline
Registriert seit: Jan 2007
Beiträge: 8
Donbuffi ist zur Zeit noch ein unbeschriebenes Blatt
Standard

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?

Geändert von Donbuffi (30-06-2007 um 12:52 Uhr)
Mit Zitat antworten
  #4 (permalink)  
Alt 02-07-2007, 00:24
Donbuffi
 Newbie
Links : Onlinestatus : Donbuffi ist offline
Registriert seit: Jan 2007
Beiträge: 8
Donbuffi ist zur Zeit noch ein unbeschriebenes Blatt
Standard

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
Mit Zitat antworten
  #5 (permalink)  
Alt 02-07-2007, 14:18
ghostgambler
 Master
Links : Onlinestatus : ghostgambler ist offline
Registriert seit: Jul 2004
Ort: DE - NRW
Beiträge: 4.620
ghostgambler ist zur Zeit noch ein unbeschriebenes Blatt
Standard

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~
Mit Zitat antworten
  #6 (permalink)  
Alt 02-07-2007, 14:32
Donbuffi
 Newbie
Links : Onlinestatus : Donbuffi ist offline
Registriert seit: Jan 2007
Beiträge: 8
Donbuffi ist zur Zeit noch ein unbeschriebenes Blatt
Standard

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.
Mit Zitat antworten
Antwort

Lesezeichen


Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
 

Themen-Optionen
Thema bewerten
Thema bewerten:

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are an


PHP News

ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlicht
ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlichtDie bekannte Marktplatzsoftware ebiz-trader ist in der Version 7.5.0 veröffentlicht worden.

28.05.2018 | Berni

Wissensbestand in Unternehmen
Wissensbestand in UnternehmenLebenslanges Lernen und Weiterbilden sichert Wissensbestand in Unternehmen

25.05.2018 | Berni


 

Aktuelle PHP Scripte

PHP Server Monitor

PHP Server Monitor ist ein Skript, das prüft, ob Ihre Websites und Server betriebsbereit sind.

11.09.2018 Berni | Kategorie: PHP/ Security
PHP WEB STATISTIK ansehen PHP WEB STATISTIK

Die PHP Web Statistik bietet Ihnen ein einfach zu konfigurierendes Script zur Aufzeichnung und grafischen und textuellen Auswertung der Besuchern Ihrer Webseite. Folgende zeitlichen Module sind verfügbar: Jahr, Monat, Tag, Wochentag, Stunde Folgende son

28.08.2018 phpwebstat | Kategorie: PHP/ Counter
Affilinator - Affilinet XML Produktlisten Skript

Die Affilinator Affilinet XML Edition ist ein vollautomatisches Skript zum einlesen und darstellen der Affili.net (Partnerprogramm Netzwerk) Produktlisten und Produktdaten. Im Grunde gibt der Webmaster seine Affilinet PartnerID ein und hat dann unmittelb

27.08.2018 freefrank@ | Kategorie: PHP/ Partnerprogramme
 Alle PHP Scripte anzeigen

Alle Zeitangaben in WEZ +2. Es ist jetzt 21:27 Uhr.