[php] Sessions und Browserfenster bzw. Tabs

[Tobias Daur]

Hi Lutz,

erstmal danke f�r die M�he die Du Dir machst (und danke f�r die
vorab-neugierigmach-pm ;)).

> Wir haben uns etwas verzettelt und drehen uns im Kreis, weil vermutlich 
> den meisten - bis heute Morgen einschlie�lich mir - nicht in G�nze klar 
> ist, worum es Dir praktisch geht. Es fehlt so ein Bi�chen der 

Jo, da sieht man mal wieder, wie kompliziert zwischenmenschliche
Kommunikation ist :)


Dein Ansatz bietet, soweit ich das ausprobiert habe, tats�chlich einen
�berschreibschutz, der auch bei mehreren Fenstern/Tabs zuverl�ssig
funktioniert. Und das ohne die �bergabe von Werten - bis auf die ID und
die Session (Cookie) nat�rlich. 
Mit der Session-Variable stellst Du sicher, da� nur der Browser mit
dieser Session schreiben kann. Da� er es nur mit dem richtigen Fenster
kann, machst Du einfach dar�ber, da� Du einen Zweitaufruf w�hrend der
Bearbeitungszeit verhinderst. 

Was mir daran nicht so gef�llt:
Du identifizierst nicht wirklich den richtigen Tab/das richtige Fenster.
Deshalb kann bei Deinem Skript auch das eigene (bearbeitende) Fenster
nicht neu geladen werden - der Reload wird blockiert.
Au�erdem begrenzt der Schutz stark die praktische Anwendung, denn Du
+ zwingst den Anwender zu einer Bearbeitung innerhalb einer bestimmten
Zeit
+ f�ngst F�lle ab, die gar nicht zu einer Kollision f�hren,
beispielsweise wenn nur einer der Bearbeiter wirklich speichert.

Damit machen wir aber ein zweites Fa� auf. 

Fa� 1: Wie realisiert man Sessions garantiert fenster/tab-bezogen? 
Das ist wieder allgemein gesprochen das Thema: Sessions identifizieren
einen Compi/Anwender. Zur Anwendungssteuerung braucht man aber IMHO
einen Mechanismus, der ein Fenster identifiziert. 

Fa� 2: Wie macht man einen 100% funktionierenden Kollisionsschutz, der
die Arbeit m�glichst wenig behindert. 

Um mal das zweite Fa� zu beackern, denn darauf zielen ja die Punkte ab,
die mir bei Deinem Modell nicht so gefallen (hmm, mu� man jetzt einen
neuen Betreff setzen?):

Ein Kollisionsschutz sollte
+ nicht zeitbasiert sein (trotz zustandslosem Protokoll)
+ nur bei einer echten Kollision greifen

Und genau dies leistet folgendes Modell:
+ jeder Datensatz bekommt einen timestamp
+ gepr�ft wird ausschlie�lich beim Schreiben
Wenn's knallt, gibt das Skript ein Diff aus, mit der M�glichkeit, die
beiden Datens�tze zu vergleichen und einen korrekten zu speichern.

Wenn ich mich nicht irre, ist das auch in etwa das, was cvs macht, oder?

In der Edelversion wird dann auch noch ausgegeben, wie der Datensatz
aussah, bevor er von einem anderen Fenster/User ge�ndert wurde. Dazu mu�
man sich den DS vor dem �ndern in der tab/fenstersicheren Session
wegspeichern. 

Und so m�chte ich den Kollisionsschutz eigentlich auch bauen - nur mit
dem von mir in meiner letzten Mail beschriebenen Problem, das entsteht,
wenn ich den timestamp in der Session zwischenspeichere und einen
zweiten Tab aufmache. 

Das Problem beim Konstruieren einer tabsicheren Session scheint ja der
Moment zu sein, in dem man einen Tab dupliziert. 
Wenn man einfach mit einem zweiten Tab auf die Site geht und lossurft,
kann man das ja, wie Sebastian es vorschl�gt, �ber eine zuf�llig
generierte Formular-ID in der Session speichern - dann h�tte dasselbe
Formular mit dem selben Datensatz, zweimal aufgerufen, einen getrennten
Eintrag in der Session. 
Nur in dem einen Fall, in dem man einen Tab mit einem Formular soeben
dupliziert hat, sind's dieselben. Vielleicht mu� man den Fall einfach
vernachl�ssigen (womit ich mir selber widerspreche ;)).

Aber ich schreibe schon wieder Romane ...


danke f�rs lesen

Tobias

-- 
Tobias Daur :: daur at gmx.de