klebende Sitzungen

Liebes Tagebuch….

Zur Zeit arbeiten wir am Clustern von 2 + n WISE Servern in einer Windows Umgebung. Die dabei auftauchenden kleinen Problemchen haben wir in den letzten Wochen und Monaten nach und nach gelöst.
Es verbleiben Aufräumarbeiten und die Feinabstimmung der Migrationsplanung.

Ein Thema das uns beschäftigt hat waren die sog. sticky Sessions. Der Nutzer soll nach einem Login, der Ihn einer Rolle mit schreibrechten zuweist, bei jeder Anfrage auf dem gleichen Server der Farm landen, damit sein Login erhalten bleibt.
Realisiert wird so etwas mit einem Session cookie, dem eine eindeutige Identifikation des betreffenden Servers mitgegeben wird. Dieses Cookie wird bei jeder Anfrage des Client durch den, dem Server vorgeschalteten Lastverteiler, hier einem Apache Server, ausgewertet und die Anfrage unabhängig von den sonstigen Verteilungsregeln an den entsprechenden WISE Server weitergeleitet.
Verliert der Nutzer seinen Login auf dem Server, muss auch das Cookie gelöscht werden, damit der Lastverteiler wieder frei in seiner Entscheidung zum routen der Anfrage ist.

Sinnvollerweise erzeugt man das Cookie in <dtml>. Die passende Identifikationsmarke bekommt man aus einem REQUEST. Hier sind einige der HTTP Parameter abgreifbar, mit denen der Browser des Nutzers die Seite Aufgerufen hat, sowie einige der serverseitigen Informationen.

TIP: Ein <dtml-var REQUEST> unter der Fußzeile in der Datei …wise\lib\python\products\wise\wise_html_footer.dtml liefert die gesamte Palette für Forschungszwecke.

Das Cookie wird durch die Anweisung

<dtml-call “RESPONSE.setCookie(‘BALANCEID’,’balanceto.’+REQUEST.get(‘SERVER_NAME’))”>

in der Datei …wise\lib\python\products\wise\wise_html_header.dtml erzeugt.
Am besten platziert man diesen Befehl in dem Abschnitt, der ohnehin prüft, ob es sich um eine Anfrage eines registrierten Nutzers handelt, um die Option für Mywise in der Menueleiste verfügbar zu machen:

……
<dtml-if “current_user != ‘Anonymous User’
and current_user != ‘Guest’
and current_user != ‘LoggingInUser'”>
<dtml-call “RESPONSE.setCookie(‘BALANCEID’,’balanceto.’+REQUEST.get(‘SERVER_NAME’))”>
<A CLASS=’Toolbar’ target=”_top” href=”view_personal” mce_href=”view_personal”>
<IMG SRC=”<dtml-var wiseRootwebUrl>/gpers_img” width=”23″ height=”16″
ALT=’Personal Page for <dtml-var current_user>’ BORDER=”0″></A>
……

Ist das nicht der Fall, soll ein entsprechend vorhandenes Cookie gelöscht werden:

…….
<dtml-else>
<dtml-call “RESPONSE.expireCookie(‘BALANCEID’)”>
<A CLASS=’Toolbar’ target=”_top” href=”<dtml-var manageable_url>?LOGIN=1″>
<IMG SRC=”<dtml-var wiseRootwebUrl>/rpers_img” width=”23″ height=”16″
ALT=’Login’ BORDER=”0″></A>
</dtml-if>
…….

Die Konfiguration des Lastverteilers sieht entsprechend routen für jeden möglichen SERVER_NAME vor.

Gotcha

Ein Kinken hat das ganze. WISE / ZOPE speichert den Wert des Cookies mit doppelten Anführungszeichen.
BALANCERID hat also den Wert “balanceto.SERVER_NAME”. Da der Lastverteiler nur den Teil nach dem Punkt auswertet, muss er auf den Wert .SERVER_NAME” prüfen um eine Route zu finden.

Zug läuft ein…. ich habe fertig