Warum ist eine Zuordnung zu einer Server-Sitzung bei möglichst sämtlichen Requests nötig ?

Bei der Online-Nutzung einer openWIM -App wird der eine Teil der Mimik im Client (= Browser) und der andere Teil in der Cloud (= im Internet-Server) ausgeführt. Dazu ist eine verlässliche Kommunikation mit Zuordnung der ausgetauschten Meldungen zwischen den Beteiligten notwendig. Dazu wird im Server eine "Sitzung ("session") erzeugt, in der die Steuerung erfolgt und auf die alle Anforderungen des Clients abgebildet werden.

Um zu erreichen, dass möglichst wenige unerwünschte Zugriffe auf den Server Erfolg haben, ist es nützlich, nur solche Zugriffe inhaltlich zu beantworten, die im Kontext einer (erwünschten) aktiven Sitzung generiert werden. Datei-Zugriffe ohne Sitzungsbezug sollten möglichst vollständig geblockt werden - es sei denn, sie kommen von erwünschten Suchmaschinen-Robotern.

Welche hauptsächlichen Hürden für eine Sitzungs-Zuordnung können wie überwunden werden ?

Zu akzeptierende Zugriffe auf den Server können unter verschiedensten Bedingungen eintreffen:

1. Der initiale Aufruf der App (resp. Internetpräsenz) erfolgt mittels eines http-"GET"-Aufrufs auf die Baisadresse der Domain plus ggf. der Angabe eines darzustellenden Objektes in der "Query" der Url oder als Angabe einer (Pseudo-)Datei (bzw. Dateipfades). Hier muss dann auf dem Server eine neue Sitzung eingerichtet werden. Die möglichst genaue Client-Adresse (IP-Adressen) und der angesprochene Service (Projekt und Client-Version) werden zur Sitzung notiert und die vom Server erzeugte Sitzungskennung (= sessionId) wird dem Client mitgeteilt.

2. Der angesprochene Service kann auf verschiedene Art spezifiziert sein. Meist wird eine bestimmte Domain mit ggf. einer Subdomain (beispielsweise flughafen.unser-forum.de) angesprochen. Soll nicht die aktuelle "Produktionsversion" der Client-Software verwendet werden sondern beispielsweise eine Vorschau-Version, wird dieses in Form einer Subdomain angegeben. Beispielsweise preview.flughafen.unser-forum.de. Im Server wird anhand einer eindeutigen Zuordnung das adressierte Projekt bestimmt und zur Sitzung notiert.

3. Bei allen zukünftigen Meldungen /Anforderungen des Clients an den Server ist im übertragenen (POST) Paket die Sitzungskennung anzugeben, damit eine eindeutige Zuordnung erfolgen kann.

   Damit sich jedoch keine "Unbefugte" in eine bestehende (möglicherweise mit Sonderberechtigungen versehene) Sitzung einklinken können, muss vom Server auch die möglichst exakte Herkunftsadresse mit den zur Sitzung notierten Angaben abgeglichen werden.

4. Wenn sich beispielsweise in Folge einer nächtlichen Zwangstrennung vom Internet die IP-Adresse des Clients ändert, muss aus Sicherheitsgründen eine neue Sitzung begonnen werden, denn sonst könnte sich jemand eventuell in eine Sitzung reinmogeln.

5. Bei Zugriffen auf Dateien im Kontext einer Sitzung können leider keine ausreichenden speziellen Identifizierungsdaten mitgeschickt werden. Zwar könnte ein Cookie-Eintrag mit der Sitzungskennung etwas Orientierung bieten, doch bei den Cookie-Daten wird nicht zwischen den Browser-Tabs unterschieden, sodass damit keine eindeutige Zuordnung erfolgen kann. Cookies sind daher defacto für die Sitzungs-Identifizierung unbrauchbar.

   Wenn jedoch der Zugriff auf Dateien des Servers über eine ausreichend spezifizierte Domainangabe erfolgt, ist unter Zuhilfenahme der immer mitgelieferten Client-Adressen und Browserkennung zumindest der verwendete Internetbrowser sauber identifizierbar. Leider aber nicht der Tab, über den der Request initiiert wurde.
   Sind mehrere Sitzungen für einen Browser aktiv, kann in diesem Fall die erste gefundene Sitzung, die dem Browser zuzuordnen ist, verwendet werden. Damit kann dann der Datei-Zugriff gestattet werden. Ist die dazu verwendete Sitzung privilegiert, die tatsächlich aber aufrufende Sitzung nicht, ergibt sich eine "Unsauberkeit", die jedoch nur in sehr speziellen Fällen relevant werden sollte.

6. Wenn sich sowohl Client als auch Server außerhalb des Internets und seines Domain-Systems befinden und "lokal" ("localhost" etc.) adressiert werden, ist unter Umständen beim Aufruf einer Datei keine saubere Erkennung des aufgerufenen Services möglich. Jedenfalls dann, wenn der Server ursprünglich mit einer Url wie localhost:/?domain=openwim.org aufgerufen wurde. Beim Erstaufruf kann damit zwar noch eine neue Sitzung eingerichtet werden und bei weiteren POST-Aufrufen wird auch die Sitzungskennung übergeben, doch bei Dateiaufrufen fehlen ausreichende Daten zur Identifizierung der zuständigen Sitzung.

   Da dieses jedoch nur bei Zugriffen passieren sollte, die im lokalen Netzwerk und nicht über das Internet laufen, kann in diesen Fällen das Blockieren von Dateizugriffen entfallen.

   Sollen auch in einem lokalen Netzwerk Dateizugriffe ggf. abgeblockt werden, helfen dagegen beispielsweise geeignete Domain-Eintragungen in der hosts -Datei von Windows. Beispielsweise "develoment.openwim.testserver".

7. Bei der Nutzung einer Internetpräsenz im Simple-Modus sind obenstehende Statements sinngemäß anzuwenden. Abweichend ist jedoch NICHT bei jedem GET-Request eine neue Sizung zu beginnen, sondern anhand des simple-mode -Parameters der Query die zugeordnete Sitzung zu ermitteln.
   Die Sitzungskennung wird NICHT bei den Query-Parametern angegeben, weil sie von den Suchmaschinen registriert und bei der Nutzung von Links der Suchmaschinen zu unerwünschten Effekten führen würde. (Der Parameterwert von simple-mode kann demgegenüber leicht als obsolet identifiziert werden und ungenutzt bleiben.)