[php] Re: [php] RE: [ php] Re: [php] Session übernehmen

[Ralf Geschke]

> Mag sein, nur weiss ich dann nicht wo der Fehler liegt.
> Es wird eine neue Session erzeugt, wenn es den (Server-)Cookie nicht gibt,
> ist der aber vorhanden, sieht PHP keinen Grund eine neue Session zu
> erzeugen.

Ich glaube, Dein Problem liegt in der Ueberpruefung von gueltigen und
ungueltigen Session-IDs. 

Situation 1: Jemand gelangt auf eine Web-Seite ohne Cookie, ohne
GET-Parameter. Eine neue Session wird erzeugt, es wird versucht, ein Cookie
zu setzen, saemtliche URLs, die auf die eigene Site verweisen, werden mit
der Session-ID als GET-Parameter erweitert. User klickt irgend eine dieser
URLs an. Die Session-Library stellt fest, ob Cookies aktiv sind und damit
verwendet werden koennen. Falls ja, werden den auf der folgenden Seite
erzeugten URLs keine GET-Parameter mehr hinzugefuegt. Falls kein Cookie
vorhanden bzw. dies abgelehnt wurde, werden eben auch den weiteren URLs jene
Parameter angehaengt. Nun klickt der User munter und lustig auf der Site
herum. Bei jedem Seitenaufruf prueft die Session-Library, ob die
uebermittelte (der Weg, ob GET, POST oder Cookie ist egal) Session-ID noch
gueltig ist. Falls ja, wird der Zeitstempel in der Datenbank aktualisiert,
so dass die Session-ID auch weiterhin gueltig ist - und zwar solange, bis
der Timeout eintritt, dies ist eine Definitionsfrage, ich wuerde hier eine
viertel bis halbe Stunde als praktikablen Wert ansehen. 

Situation 2: User hat eine Stunde lang nichts getan, oder den GET-Parameter
und somit die Session-ID mutwillig geaendert: Session-Library stellt fest,
dass die uebergebene Session nicht mehr gueltig ist (oder nie gueltig war)
und erzeugt eine neue Session-ID, das Spiel wie oben beschrieben beginnt von
vorne. Oder es wird eine Warnmeldung angezeigt - dabei kann dann noch
unterschieden werden, beispielsweise "Sitzungsdauer ueberschritten", falls
die Session-ID zwar existiert, aber inzwischen aufgrund der zu langen
Zeitspanne zwischen zwei Aktionen als ungueltig erklaert wurde, oder eine
andere Meldung wenn die Session-ID nicht in der Datenbank steht, oder
niemals eine Session-ID war, beispielsweise falls aus einer zu geringen
Anzahl von Zeichen bestehend. 

Dabei macht es auch keinen Unterschied, ob Cookies verwendet wurden oder
nicht - solange die Session-Library korrekt feststellt, ob die Session-ID
noch gueltig ist oder nicht. 

Natuerlich gibt es immer Hintertueren - etwa wenn das Zeitlimit noch nicht
ueberschritten wurde und wenn ein User in diesem Zeitraum mit einer fremden
Session-ID per GET-Parameter die Seite betritt. Hier hilft bereits der
Dereferer einiges - wie das am besten gemacht wird, wurde ja in den von Dir
angegebenen Artikel beschrieben. Wenn nun aber doch ein User mit einer
"fremden" Session-ID eintreten wuerde, koennte er die Daten des anderen
Users uebernehmen. Ja. Daran laesst sich aber auch vom Prinzip her nichts
aendern, ausser, Du laesst den User sich ausloggen. Ob das fuer Deine
Anwendung sinnvoll ist oder nicht, kannst nur Du entscheiden. Bei
sicherheitskritischen Anwendungen wie Online-Banking beispielsweise ist es
sinnvoll (abgesehen davon dass ich sowas nicht an oeffentlichen Orten
wie Internet-Cafe betreiben wuerde...), ebenso bei Webmail-Diensten, in
gewisssem Sinne auch eine Art Communiy-Anwendung, und hier gibt es
schliesslich auch jene Logout-Buttons. 

Bei anderen Anwendungen oder wenn Du ein Nutzungsverhalten voraussetzen,
indem der User beispielsweise nur von seinen privaten PCs zugreift, mag man
darauf verzichten koennen oder wollen, diese Entscheidung kann Dir aber
keiner abnehmen. Du kannst einzig die Moeglichkeit anbieten und - eben
aufgrund der Sicherheit - die Nutzung empfehlen. Das schliesst
Manipulationen vielleicht nicht gaenzlich aus, macht sie aber aufwendiger. 

Andernfalls heisst es eben, mit den potentiellen Problemen einfach zu leben,
es bleibt einem auch gar nichts anderes uebrig. Die Frage lautet somit,
welche Massnahmen fuer Deine Anwendung sinnvoll sind - je nach
Nutzungsverhalten koenntest Du z.B. die Sitzungsdauer, d.h. die Zeit, nach
der die Sitzung bei Nichtaktivitaet als ungueltig erklaert wird,
erniedrigen. 

> > Selbst wenn nun mit Sessionid gelinkt wird, wird eine neue erstellt.
> > Aber nur einmal. Diese neue (eine ID) hat der User dann natürlich für die
> > ganze
> > Verweildauer.
> 
> Ja und? Was ist wenn ich ein neues Fenster aufmache?

Was soll dann sein? Wenn Du ein Link in einem neuen Fenster oeffnest, wird 
die im GET-Parameter oder Cookie vorhandene Session-ID beim Aufruf der Seite
geprueft und ggf. verwendet. 
Wenn Du ein neues Fenster oeffnest und darin eine URL zu Deiner Seite
eingibst, findet eine derartige Pruefung logischerweise nur statt, wenn
Cookies verwendet werden, andernfalls wird eine neue Session erzeugt. Aber
wo ist das Problem? Oder anders: Wer macht sowas? Wozu sollte der User ein
neues Fenster oeffnen und darin eine URL eingeben, wenn er es viel einfacher
haben koennte durch Klick auf die rechte Maustaste und einem weiteren Klick
auf den richtigen Menuepunkt? Andernfalls ist er eben selbst schuld - und
erhaelt eine neue Session-ID, mit der er beispielsweise nicht eingeloggt
ist - und darf sich neu einloggen, sofern er in dem neuen Browserfenster
weitermachen will. 
Insofern stimmt zwar das, was Bjoern erwaehnte, aber ich frage mich
ernsthaft, ob dies Verfahren in der Praxis wirklich angewandt wird - also
neues Browserfenster oeffnen und URL angeben anstatt mit Klick auf die
mittlere Maustaste (ach ja, Linux... ;-) ) den aktuellen Link in einem neuen
Fenster zu oeffnen. Und zu guter Letzt haettest Du die Moeglichkeit, Deinen
Usern kurz zu erklaeren, dass es zu diesen oder jenen Seiteneffekten kommen
kann...

Beste Gruesse,
   Ralf
-- 
: www  : http://www.ruby-center.de  :  http://der.leitweganzeiger.de
: mail : ralf_(at)_ruby-center.de       :::         rg_(at)_leitweganzeiger.de