Teilnehmer

web.sta – web basierte Appli­kation, Ziel-Webbrowser ist Internet Explorer der Version 9 und 11

TextSystem – eine eigen­ständige Desktop-Anwendung, basierend auf Java/Swing

Inter­me­dia­te­Layer – eine Client-Server Anwendung, die web.sta und TextSystem mitein­ander verbindet.

web.sta kann TextSystem über den Inter­me­dia­te­Layer starten. Inter­me­dia­te­Layer erstellt zu diesem Zweck einen HTTP-Server und web.sta sendet einfache GET- oder POST-Abfragen an den localhost. Inter­me­dia­te­Layer verar­beitet die Eingangs­pa­ra­meter und startet das TextSystem. Da keine Rückmeldung erfor­derlich ist, ist das Inter­ak­ti­ons­schema einfach und robust genug.

Citrix

In einer Citrix-Umgebung ist es nicht möglich, mehrere Listening-Sockets für dieselbe IP-Adresse und denselben Port zu erstellen. Man muss entweder den Port oder die IP-Adresse ändern. Citrix bietet jedoch einen spezi­ellen Mecha­nismus an, um diese Einschränkung zu umgehen, ohne den Algorithmus des Programms zu ändern. Dieser Mecha­nismus wird als „Virtual IP Loopback“ bezeichnet. Hier muss der Adminis­trator einfach die erfor­der­lichen Anwen­dungen im Citrix-Konfi­gu­ra­ti­ons­fenster konfi­gu­rieren. Die Anwendung, die „localhost“ für Socket-Verbin­dungen verwendet, erhält nicht 127.0.0.1, sondern eine IP-Adresse in der Form 127.0.0.<SID + 1>, wobei SID die Sitzungs-ID des Windows-Benutzers ist.

Die Proble­matik

Unter IE9 (und auch mit anderen Browsern) unter Windows Server 2008 R2 funktio­nierte dies alles einwandfrei. Dann jedoch wollte der Kunde etwas Neues und Windows Server 2012 R2 erschien mit IE11. Das ganze System hörte auf zu funktio­nieren. Unabhängig von den Citrix Einstel­lungen versucht IE11 bei Abfragen auf „localhost“ immer eine Verbindung zu 127.0.0.1 herzu­stellen, diese natürlich scheitert, weil auf der Adresse keiner Hörer (Listener) gibt. Nach ein wenig Recherche kamen wir zu dem Schluss, dass dies ein Bug in IE11 sein muss.

Routing­Service

Wenn die Virtua­li­sierung des „localhost“ in Citrix-Box für IE11 nicht funktio­niert, schreiben wir sie selbst!
Deshalb entschlossen wir uns, selbst einen Windows-Dienst zu erstellen, der ein einfacher Webserver ist und zu 127.0.0.1 eine Verbindung aufbaut und damit alle Abfragen auf der Grundlage der Sitzungs­nummer des Benutzers an den gewünschten Inter­me­dia­te­Layer umleiten. Wir haben keine einfache Lösung gefunden, um die SID zu ermitteln, aber in den Umgebungs­va­riablen haben wir sofort SESSI­ONNAME gefunden. Im Internet Explorer bekommen wir über ActiveX diese Umgebungs­va­riable und übergeben sie als Parameter in der HTTP-Abfrage weiter. Im Routing­Service erhalten wir durch den Sitzungs­namen unter wtsapi32.lib die Sitzungs­nummer. Dann leiten wir die HTTP-Abfrage um und senden die Antwort an den IE zurück.

Etwas ist schief gelaufen

Wir haben mit dem Testen und der Integration unseres Service begonnen. Aber nicht alles lief so reibungslos, wie wir es uns gewünscht hatten.
Wie sich heraus­stellte, kann der Name der Sitzung geändert werden, obwohl wir nicht verstanden haben, unter welchen Bedin­gungen dies geschieht. Es kam jedoch häufig vor, dass der Sitzungsname geändert wurde aber IE11 nur den Anfangswert der Umgebungs­va­riablen kennt und diesen Wert dauerhaft an den Routing­Service weitergibt.

Was ist in der Registry?

Es war notwendig, einen anderen Weg zu finden, um den Sitzungs­namen zu ermitteln. Wir haben nach Infor­ma­tionen zu Sitzungen in der Registry gesucht und wurden fündig: Unter HKEY_CURRENT_USER \ Volatile Environment ist es möglich eine Liste aller Sitzungen des aktuellen Benutzers abzurufen.

Wenn es nur um eine Anmeldung geht, ist alles in Ordnung, wir können sie lesen und verwenden. Wenn es für einen Benutzer jedoch viele Sitzungen gibt, müssen wir irgendwie feststellen, in welcher Sitzung wir uns befinden. Die beste Möglichkeit die uns einfiel war, den Pfad zum Ordner mit den tempo­rären Dateien abzugleichen.

Beispiel:

Im IE erhalten wir den aktuellen Pfad zu TEMP mithilfe von ActiveX Scripting.FileSystemObject. Auf diese Weise konnten wir den Namen unserer Sitzung ermitteln. Aber das ist nicht alles. Der Wert der Schlüssel in der Volatile Environment ist in der Tat die SID. Somit können wir sofort die erfor­der­liche IP-Adresse in JavaScript abrufen und eine Anfrage an diese senden.

Sollen wir es vereinfachen?

Schließlich können wir die SID abrufen und direkt eine Verbindung herstellen, ohne den Routing­Service zu verwenden. Aber der Lösungsweg sieht immer noch nicht schön aus. Die Inter­net­suche hat gezeigt, dass das Problem besteht, aber wie es behoben werden kann wird nirgendwo beschrieben. Und auch Microsoft bietet dazu bisher keine Lösung.

Wir hoffen, dass jemand mit diesem spezi­fi­schen Problem von unserer Erfahrung profi­tieren kann.