Michael Schröpl: Session Managment nicht übe URL bzw. Cookie?

Beitrag lesen

Hi Christian,

Wenn Mehrfach-Login inhaltlich nicht gebraucht wird, aber Cookies als lästig
empfunden werden ...
... muss man immer noch einen betraechtlichen Programmier-Aufwand
betreiben, um den Mehrfachlogin zu verhindern.

Wenn der Kunde es bezahlt, wieso nicht?
(Wenn Du wüßtest, was ich schon für Kundenwünsche realisieren durfte ...)

Die besage Kollisions-Kontrolle kostet beispielsweise fast nichts, wenn
die Authentifizierung ohnehin auf eine Datenbank zugreifen muß - mit einer
Transaktion kann ich problemlos auch die Session-ID in die Zeile der Be-
nutzerkennung reinschreiben bzw. aus ihr lesen.

Besonders nicht unter dem Aspekt, dass User gerne vergessen, sich
auszuloggen und die Session dann in den Timeout laufen muss. Ist der
relativ kurz, ist alles ok.

Das Problem hast Du aber _immer_ bei Sessions, weil HTTP eben ein
zustandsloses Protokoll ist. Die Benutzer loggen sich _nie_ aus.
Du brauchst _immer_ den cleanup-Job bzw. den Timeout. Und Du brauchst
eine Strategie, ob ein zweites login ein erstes überschreiben soll oder
nicht.

Aber ich glaube nicht, dass ein User verstaendnis dafuer hat, wenn er
eine halbe Stunde warten darf, dass er sich neu einloggen kann. *Ich*
haette es nicht.

Du scheinst kein Kunde einer online-Bank zu sein.
Genau dieses Blockieren ist (bzw. war?) dort schon aus Sicherheitsgründen
der Defaultfall, um Angriffe mit Passwort-Ausprobieren abzuwehren.

Manchmal geht Sicherheit vor Komfort - vor allem dann, wenn es um sehr
viel Geld geht. Eine Raumfähre ist auch nicht in erster Linie bequem. ;-)

Viele Grüße
      Michael
(der ein Session-Management-System mit Cookies produktiv einsetzt, bei
 dem die overruling-Strategie pro Benutzergruppe konfigurierbar ist ;-)