[php] Sessions und Browserfenster bzw. Tabs

[Tobias Daur]

Hi,

danke Euch dreien für die Rückmeldungen. Ich fasse das einfach mal in
einer Mail zusammen ...

Ok, offenbar reicht eine Session allein in der Regel nicht aus, um ein
Fenster/einen Tab zuverlässig zu betreuen. 

Du, Lutz, hast die möglichen Fälle wunderbar aufgedröselt.

Also braucht man eine Lösung, die weder aus nem Cookie noch aus ner
Session-ID besteht. 

Vorschläge von Sebastian:
+ Mitnehmen von IDs ins Formular, Speichern in der Session
kontextspezifisch.

Das kontextspezificshe Speichern tut's IMHO nicht in dem Fall, in dem
man mit beiden Fenstern/Tabs im gleichen Formular hin- und herwuselt.

+ Die Formulare bekommen Hashs/TIDs
Damit haben wir eine Art Sesion in der Session gebildet, müssen also in
den HTML-Code zumindest ein Hidden Field bzw. einen Link-Parameter
schreiben. Können dann aber die eigentlichen Werte in der Session
lassen, immer in einem Array, der den Hash als Key hat. 

Was ich dann aber nicht verstehe, ist, warum Du, Thorsten, der Du das ja
auch vorschlägst, dann bei Euch das nur zur Vermeidung eines zweiten
Fensters verwendet hast und nicht dazu, die Fenster eindeutig zu
identifizieren. 

Spricht da was dagegen? 

(Bis auf die Tatsache, daß es mehr Arbeit ist, als man sich eigentlich
machen möchte ...)



> > Das bedeutet, daß ich, wenn ich eine fehlerfreie Verwendung von mehreren
> > Fenstern ermöglichen will, keine Sessions verwenden kann.
> 
> Was hat das mit der Session zu tun? :-) Wenn es um Datenabhängigkeiten
...
> Dein Problem ist aber nicht die Datenspeicherung an sich, sondern die 
> Steuerung der Speicheraktionen über
> mehrere Fenster hinweg, quasi in Raum und Zeit. :-)

Na, ich möchte ja genau das tun, wofür Session zuständig sind: Bei einem
zustandslosen Protokoll die Dinge zwischenspeichern, die man sich von
Aufruf zu Aufruf merken möchte. Natürlich Fenster/Tab-spezifisch.
Offenbar können Sessions aber genau das nicht. Nicht alleine.

[Kollisionsschutz]
> Also wenn es um Kollisionsschutz geht, dann ist die Session sicherlich
> nicht der richtige Platz zur Speicherung der Daten die einen
> Zugriffskonflikt verhindern sollen. Du gehst ja selbst davon aus, daß die
> Session im Normalfall nur dem aktuellen Anwender zur Verfügung steht. Was
> ist aber nun, wenn zwei Anwender von zwei verschiedenen Rechnern aus
> gleichzeitig versuchen, auf die Daten schreibend zuzugreifen? Einen
> solchen Zugriffskonflikt kannst Du doch nicht angemessen behandeln, wenn
> Du die relevanten Daten nur in der Session der jeweiligen Anwender hältst.

Nee, das ist IMHO kein Problem. Genau dafür ist die Session da.

So dachte ich mir den Kollisionsschutz:

Jeder Datensatz hat nen Timestamp.
Beim Laden des Datensatzes wird der Timestamp in die Session
geschrieben.
Beim Schreiben wird der Timestamp aus der Session mit dem in der DB
verglichen, sind sie verschieden, knallt's. 
Das geht im Prinzip. Nur nicht bei zwei Tabs.
Dann passiert folgendes:

Person 1 liest 
Person 2 liest
Person 1 schreibt -> timestamp anders
Person 2 liest mit neuem Browserfenster -> session-timestamp wird
überschrieben
Üerson 2 schreibt mit altem Browserfenster -> es müßte knallen, tut's
aber nicht, da der timestamp in der session mit dem in der DB
übereinstimmt.

> Das kommt auf das konkrete Szenario an. Wie sieht das bei Dir denn aus?
> Hier wird leider immer nach Lösungen gefragt, ohne die Aufgabe zu nennen.

Ich denke mal, das eben beschriebene ist konkret genug. Und ist nur das
Beispiel zu dem in meiner ersten Mail beschriebenen Fall. 

Allerdings scheint mir die Aufgabe "baue eine garantiert
fenster/tabspezifische Session" (damit man nix im HTML-Code mitschleifen
muß) eigentlich recht klar, gelle? ;)

Danke schon mal für's mitdenken

Tobias


-- 
Tobias Daur :: daur at gmx.de