[php] Fw: [php] Lange Leitung

[Kristian =?iso-8859-1?Q?K=F6hntopp?=]

Alex Killing wrote:
> Kristian Köhntopp schrieb:
> > [...]
> > "Bitte geben Sie Ihren Nachnamen und Ihr Kennwort ein:
> >
> > [Logo]
> >
> >     Name    :
> >     Vorname :
> >     Telefon :
> >     Kennwort:
> >                      [Hilfe] [ Log in ]
> >
> >     Wenn Ihr Nachname nicht eindeutig ist ("Müller"), geben Sie
> >     bitte ihren Vornamen und ggf. auch ihre Durchwahlnummer mit ein."

> Na ein Glück ! Solche Anmeldungen der obigen Art gehören ja wohl
> verboten. Ich geb doch nicht bei jeder Anmeldung meine halbe Adresse
> ein, [ ... ]

Das brauchst Du auch nicht, solange Dein Name eindeutig ist. In
solchen Fällen genügt die Angabe von Name und Kennwort. Nur Anwender,
bei denen der Teilschlüssel Name nicht eindeutig ist, müssen mehr
Informationen eingeben. Je nach Grad der gewünschten Sicherheit
kann das System dabei mehr oder weniger unterstützend tätig werden -
der Punkt bei solchen integrierten Anmeldeformularen im Gegensatz
zu http-Auth ist ja gerade, daß man hier Designflexibilität hat,
um den Anmeldeprozeß im Aussehen, Verhalten und im gewünschten Grad
der Sicherheit für die Zielgruppe anzupassen.

> Und dieses kleine http-auth-Fenster ist nicht CI/CD
> konform - soll ich denn in jeder Sicherheitsabfrage noch ein Firmenlogo
> unterbringen ?

Ja, und nicht nur das, sondern auch dort sollte das Hilfesystem der
Anwendung zur Verfügung stehen, um den Benutzer zu unterstützten und
zu führen. Gerade in einer Anmeldesituation sind unerfahrene Benutzer
und Gelegenheitsanwender oft unsicher, weil sie das System als nicht 
abweisend oder gar als feindselig empfinden und daher ist es hier besonders
wichtig, durch Einbettung in die Optik des Gesamtsystems und durch
die Bereitstellung von Führung den Anwender zu unterstützen.

> Nach einem HTTP-Auth, hab ich alles was ich brauch. Der DB Zugriff, oder
> das nachlesen in der ASCII-Datei <grusel>, erfordert dann nochmal 3
> Zeilen Code.

http-Auth gegen eine ASCII-Datei erfordert ein getrenntes Pflegen eines
unter Umständen schon vorhandenen Benutzerdatenbestandes, der in anderen
Kundensystemen oft schon vorhanden ist (Kunden-Datenbank, Mitarbeiter-
Bestandsdaten und dergleichen mehr). http-Auth läßt sich nicht gut in
solche existierenden Datenbanken integrieren, auch dann nicht, wenn sie
gegen eine Datenbank authentisiert (Name und Struktur der Tabelle, Art
des Datenbanksystems sind eingeschränkt). Ein System wie PHPLIB es verwendet
ist einerseits demgegenüber vollkommen frei im Interface, da man sich
den entsprechenden Callback selbst erstellen kann, bietet andererseits
in den mitgelieferten Beispieldateien einen Anmeldemechanismus nach dem
Schema "http-Auth" ohne eine eigene Zeile Code...

Dazu kommt speziell im Falle von PHPLIB noch "reg"-Mode, indem man statt
eines Loginfensters auch ein Registrierfenster aufgehen lassen kann. Der
Anwender kann sich so selbst eintragen und beim System registrieren, dem
so erstellten Account werden Default-Rechte zugewiesen. Ein Operator kann
die so erzeugten neuen Accounts untersuchen und sie ggf. upgraden...

> Ich muß aber zugeben, daß ich keine Ahnung habe was ein
> Challenge-Response-Mechanismus ist.

Siehe meine Mail von vorhin.

> Eine Session ist imo ein ziemlich willkürliches Objekt. 

Eigentlich nicht. Eine Session ist relativ gut definiert, nämlich als
die Sequenz aller Zugriffe eines Browsers auf eine bestimmte Präsentation,
d.h. eine Session hat zwei beteiligte Parteien (meine Anwendung und
den Benutzer bzw. seinen Browser), einen zeitlichen Rahmen mit einem
Anfang und einem Ende und vor allen Dingen auch eine Ordnung (die
Reihenfolge der Zugriffe kann eine Rolle spielen).

Eine Session hat zunächst auch einmal nichts mit Identitäten oder
Anmeldeprozessen zu tun, sondern nur mit der Einordnung von ehemals
kontextlosen Zugriffen auf einzelne Seiten einer Präsentation in
eine Zugriffsgeschichte für jeden einzelnen Browser ("Weil der Anwender
vorhin in der Katalogseite auf das Kondom geklickt hat, ist jetzt
ein Zehnerpack Billy-Boy in seinem Warenkorb auf der Bestellseite zu
sehen."). Sessions verschaffen dem Abrufer und der Anwendung also eine
gemeinsame Geschichte, ein Erinnerungsvermögen - das ist die Sache
mit dem Retten von Variablen auf der Serverseite, statt sie als
HIDDEN-Variablen durch die Gegend zu schaukeln.


Sessions können optional authentisiert sein, d.h. der Benutzer einer
Session behauptet eine bestimmte Person zu sein ("Identifikation"),
kann dies auch durch Kenntnis des zu dieser Identität gehörenden
Geheimnisses beweisen ("Authentifizierung", "die behauptete Identität ist
autentisch") und die Anwendung kann der Benutzeridentität bestimmte
Rechte zuordnen ("Autorisierung").

"authentisiert sein" ist eine Eigenschaft einer Session zu einem
gegebenen Zeitpunkt (wir erinnern uns: Reihenfolge spielt in einer
Session eine Rolle): Eine Session ist erst ab einem gewissen Zeitpunkt
(nach korrekter Eingabe des Geheimnisses) authentisiert und in einigen
Implementationen (z.B. PHPLIB) ist sie auch nur bis zu einem gewissen
Zeitpunkt authentisiert ("Autologout").


Wenn man jetzt noch einmal abstrahiert, dann erkennt man zwei Identitäten,
die in authentisierten Sessions auftreten: Session-IDs, die Browser und
Variablenbestand auf dem Server aneinander binden und User-IDs, die 
in authentisierten Sessions den Session-Record und den User-Record
aneinander binden. Entsprechend kann man mit zwei Sätzen Variablen
arbeiten: Mit Session-Variablen, die an die Session-ID gebunden sind und
mit User-Variablen, die an die User-ID gebunden sind.

PHPLIB kennt in der Klasse "Session" Session-Variablen. Sie existieren
auf jeder Session-Seite und sie haben eine Lebensdauer, die der einer
Session entspricht, d.h. üblicherweise sind sie weg, wenn der User die
Session beendet, indem er sie einige Zeit stehen läßt oder indem er den
Browser beendet. Typische Session-Variablen sind ein Warenkorb oder andere
Variablen, die Klickgeschichte schreiben.

In der Klasse "User" kennt PHPLIB User-Variaben. Sie existieren nur in
authentisierten Session-Seiten und sie haben eine unbegrenzte Lebensdauer,
d.h. sie sind nach der Anmeldung des Benutzers immer wieder verfügbar. Typische
User-Variablen sind Benutzervoreinstellungen, Kreditkartennummern oder
Lieferadressen.

> Ok, eine Anwendung gibt es dann doch : die "anonyme Session". Da kann
> man dann Ralfs oder Deinen Lösungsvorschlag nehmen. Meine Einwände hier
> richten sich übrigens nicht gegen PHPLIB, die bietet einem ja noch
> einiges mehr.

Der Kern von PHPLIB bietet vor allen Dingen einen aufgeräumtes Framework, 
indem die unterschiedlichen Konzepte Session, Authentication, 
Permission/Authorization, User und so weiter nicht durcheinander geworden 
sind und eine standardisierte API, mit der man diese Konzepte dann umsetzen kann.

PHPLIB stellt dann eine Implementierung desjenigen Teils dieses Frameworks
dar, der von einer einzelnen, konkreten Webanwendung unabhängig ist (und das
ist schon eine ganze Menge Code) und der zur Abwechslung mal ein wenig Review
gesehen hat und deswegen hoffentlich weniger Fehler enthält als das, was Du
für eine einzelne Anwendung aus dem hohlen Bauch selber coden würdest (PHPLIB
enthält auf jeden Fall weniger Fehler als wenn _ich_ das mal eben so selber
coden würde...).

Ich gebe ja zu, daß es im ersten Moment aufhält und vielleicht am Anfang sogar 
weh tut, sich da einmal Gedanken drüber zu machen und sich das Schema, das 
PHPLIB bereitstellt anzutun. Langfristig zahlt sich das aber nach meiner
Erfahrung aus.


In diesem Zusammenhang auch noch einmal ein paar Worte zu s2lib von Ralf
Geschke, die allerdings mit ein wenig Vorsicht zu genießen sind, weil s2lib
einerseits sehr wenig Doku hat und andererseits ich s2lib nicht ausprobiert
habe, sondern hier auf der Basis der Callnamen rede (http://kuerbis.org/s2lib/slib.de/).

PHPLIB hat nicht ohne Grund die Struktur, die sie jetzt hat. Ältere Versionen
von PHPLIB bestanden ähnlich s2lib jetzt aus einer einzigen Klasse mit einer 
einzigen Include-Datei, die alle Funktionen (Session, Auth, Perm) in einer 
einzigen Klasse abgehandelt hat. Es hat sich herausgestellt, daß dies zunächst 
einmal leichter zu coden war, letztendlich aber hinderlich war, weil es 
verschiedene Dinge zusammengelegt hat, die man getrennt betrachten sollte. 
Tut man dies nicht, verquast man einige Ideen in seinem Kopf und in der Folge
in seinem Code - bei größeren Projekten ist dies leidvoll getestetermaßen
tödlich.

Naja, wahrscheinlich interessiert das alles gar keinen mehr...

Kristian

-- 
Kristian Köhntopp, NetUSE Kommunikationstechnologie GmbH
Siemenswall, D-24107 Kiel, Germany, +49 431 386 436 00
Using PHP3? See our web development library at
http://phplib.shonline.de/ (GPL)