Participants
web.sta – web-app, target browser is Internet Explorer 9 & 11
TextSystem – standalone desktop application, written in Java/Swing
IntermediateLayer – Client-Server app, linking web.sta and TextSystem together.
web.sta can call TextSystem via the IntermediateLayer. IntermediateLayer creates an HTTP server for this purpose and web.sta simply sends GET or POST requests to the localhost. IntermediateLayer processes the request parameters and starts the TextSystem. There is no need for feedback calls, so the interaction scheme is simple and robust enough.
Citrix
In Citrix environment we can not create several listening sockets on the same IP address and port. It is necessary either to change the port, or to change the IP address. But Citrix provides a special mechanism for circumventing this restriction, without changing the algorithm of the program. This mechanism is called Virtual IP Loopback. The administrator simply configure necessary applications in the Citrix configuration panel and the application that uses localhost for socket connections will receive not 127.0.0.1, but an IP address in the form 127.0.0. <SID + 1>, where SID is the session ID of the Windows user.
The Problem
All this worked fine under IE9 (and with other browsers too) on Windows Server 2008 R2. And then the clients wanted something new and Windows Server 2012 R2 appeared with IE11. And the whole system stopped working. Regardless of Citrix IE11 settings, when specifying “localhost” it always tries to establish a connection to 127.0.0.1, but nobody listens there. After a little research, we came to the conclusion that this is a bug in IE11.
RoutingService
If the virtualization for localhost does not work out of the Citrix box for IE11, then let’s write it ourselves!
For these purposes, we decided to write a windows service, which will be the simplest web server, listen to 127.0.0.1 and redirect requests to the desired IntermediateLayer, based on the session number of the user. We did not find a simple solution to get the SID, but we immediately found SESSIONNAME in the environment variables. In IE via ActiveX we get the environment variable, pass it as a parameter to the HTTP request. In RoutingService by the sessionname through wtsapi32.lib we get the session number. Then we redirect the HTTP request and return the response to IE.
Something went wrong
We began the testing and integration of our service. But not everything went as smooth as we would like.
As it turned out, the name of the session can be changed, although we did not understand in what conditions it happens. But often it happened that the session name changed, and IE11 only knows the initial value of the environment variable. And persistently passes this value to the RoutingService.
What is in the registry?
It is necessary to find another way to get the sessionname. We have looked for information about sessions in the registry and that’s what they found: in HKEY_CURRENT_USER \ Volatile Environment we can get a list of sessions of the current user.
If the user session is one, then everything is fine, we can read and use it. And if there are a lot of sessions for one user, then we need to somehow determine which session we are in. We could not come up with anything better than matching the path to the temporary files folder.
Here is an example:
In IE, we get the current path to TEMP using ActiveX Scripting.FileSystemObject.
This way we managed to get the name of our session. But that’s not all. The value of the keys under the Volatile Environment is, in fact, the SID is. That is, we can immediately get the necessary IP address in JavaScript and send a request to it.
Shall we simplify it?
Finally we can get the SID and establish a connection directly, without using RoutingService. But the solution still does not look beautiful. Studying the Internet showed that the problem exists, but the solution to this problem is not described anywhere. And the Microsoft keeps silence as well.
We hope someone with this specific problem can benefit from our experience.
