nicht angemeldet
Tach!
(a) Daten in der Session ablegen
(b) Daten serialisieren und dann in einem hidden-Feld im folgenden Formular ablegen.
Die richtige Antwort lautet a. Nur wenn man keinen Session-Mechanismus zur Verfügung hat, wäre b akzeptabel.Aber damit verhindere ich doch, dass der Workflow in zwei Browsertabs (also mit derselben Session) "gleichzeitig" bearbeitet wird.
Richtig. Von zwei Workflows in derselben Browser-Instanz war aber in deinen Anforderungen bisher nicht die Rede.
Ist das sinnvoll? Oder speicherst du die Daten in der Session unterhalb eines "Workflow"-Keys, den du zu Beginn des Workflows erzeugst?
Was sinnvoll ist, hängt letztlich stark von der Aufgabenstellung ab. Wenn du die Daten der jeweils nicht aktiven Formulare über den Client schleifst, sind sie ja zu einem bestimmten Zeitpunkt entweder in der Scriptinstanz auf dem Server oder in der Formularinstanz im Browser. Damit kommen sie nicht mit den Daten der anderen Workflows in Berührung, die ja in eigenen Seiten- und Script-Instanzen laufen. Sie ständig zwischen Client und Server hin- und her zu übertragen kostet aber mindestens Traffic. Die Manipulationsmöglichkeiten auf dem Client sind solange vernachlässigbar, solange es sich nur um die vom Anwender sowieso über die Formulare änderbaren Eingabedaten handelt. Bei bereits berechneten Zwischenergebnissen sieht die Sachlage jedoch schon wieder anders aus.
Das Problem bei mehreren Workflows in demselben Browser ist im Prinzip nur vom Session-ID-Cookie verursacht, der im Browser per Domain verwaltet wird und damit in allen Tab/Fenster-Instanzen derselbe ist. Wenn die Session-ID per URL- oder POST-Parameter übertragen wird, wären damit auch getrennte Sessions auf dem Server möglich. Zumindest die URL-Variante zieht weitere Sicherheitsbedenken nach sich, die man gern vermeiden würde.
Im Rennen ist damit noch eine für jeden Workflow eindeutige, über ein Hidden-Input separat mitgeführte Session-ID, die nur in POST-Daten, nicht jeoch über URL/GET transportiert wird. Nach dem gleichen Prinzip funktioniert der von dir vorgeschlagene Workflow-Key. Bei einer über Cookies weitergereichten Session-ID braucht es ein zweites Identifizierungsmerkmal, das einen anderen Weg gehen muss, um nicht der Cookie-Beschränkung zu unterliegen. Das kann der Workflow-Key oder besser vielleicht Workflow-ID benannt) sein. Diese W-ID kann eigentlich sogar über GET/URL übertragen werden, denn allein ohne die Session-ID im Cookie nützt sie keinem etwas.
Getrennte Session-IDs per Cookie gehen aber auch, wenn du den Cookies individuelle Pfade mitgibst (Default ist ja /). Wenn du also deine Workflow-ID in den Pfad einbauen kannst, kannst du darüber getrennte Sessions verwalten. Das braucht dann aber weitere Maßnahmen auf dem Server, wie zu Beispiel mod_rewrite. Individuelle Subdomains gingen auch, sind aber gleich noch viel unhandlicher, weil da auch noch das DNS in Mitleidenschaft gezogen werden muss.
Alles in allem stellt sich für mich eine ohne Verrenkungen per Cookie mitgegebene Session-ID und eine Hidden-Input-Workflow-ID als die einfachste Lösung dar.
dedlfix.