Michael Schröpl: Cookies o.ä.

Beitrag lesen

Hi Michael,

Dasselbe gilt, wenn der Benutzer sich über ein Formular 'anmeldet',
von Deiner Site einen Cookie mit dem Inhalt seiner Anmeldung gesetzt
bekommt [...]
genau an sowas dachte ich,

Das hatte ich befürchtet. ;-)

aber ich kann mir in der richtung kein bild machen.

Es sind auch noch jede Menge Freiheitsgrade drin. Du kannst Dir aussuchen,
mit welcher serverseitigen Intelligenz Du das Formular auswertest, einen
Cookie daraus bastelst und diesen als Bestandteil des HTTP-Headers an den
Browser sendest - und bei nachfolgenden Aufrufen dann immer wieder prüfst,
ob der Cookie vorhanden ist und was drin steht. Da gibt es massenhaft
Möglichkeiten: Perl, PHP, ASP, JSP, ... kommt halt darauf an, was Du kannst
und was Du darfst.

Bei Server Authentication brauchst Du das alles nicht zu programmieren -
das erledigt der Webserver für Dich. Deine dynamische Seite (CGI, SSI, ...)
erhält die Benutzerkennung als Environment-Variable und fertig.

Deshalb würde ich so etwas generell nur dann selbst bauen, wenn ich mehr
übertragen muß als eine Identität - beispielsweise, wenn ich die Eindeutig-
keit der Kommunikationsinstanz technisch sicherstellen muß.
Wenn ein Benutzer bei Dir zweimal 'angemeldet' ist, dann tut das Deiner
Logik nicht weh, also reicht eine Benutzerkennung; wenn ein Benutzer
dagegen mit derselben Kundennummer etc. in einem online-Shop gleichzeitig
zweimal angemeldet ist, dann darf der Shop nicht mit den beiden Warenkörben
dieses Kunden durcheinander kommen. Deshalb wäre im letzteren Fall vermut-
lich eine zusätzliche Session-Kontrolle erforderlich - und dafür muß dann
zusätzliche Information übertragen werden, um diese beiden Sessions von-
einander zu unterscheiden.
Beispielsweise eben in Form eines Cookies mit einer Session-Nummer drin.

ich brüchte etwas zum abgucken.

Das hatte ich auch befürchtet. :-\ Dazu müßte ich aber - wie oben erwähnt - weitere Randbedingungen kennen.

Viele Grüße
      Michael