Is there a way to bind the TSPlus web server for HTML 5 clients to a specific IP address?
Yes, but this requests specific knowledge, is not supported by GUI and supported only in newest release.
Take a look in "webser" folder of Tsplus installation for file name "runwebserver.bat"
On each start of server this file gets rewritten, so it is important to set read-only option on this file if you are going to change the settings.
Usually the standard line looks like that
@"C:\Program Files (x86)\Java\jre1.8.0_25\bin\HTML5service.exe" -XX:+UseFastAccessorMethods -XX:+AggressiveOpts -XX:+UseBiasedLocking -XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=10 -cp "%~dp0httpwebs.jar" -Duser.dir="C:\\Program Files (x86)\\TSplus\\Clients\\www" com.jwts.socketjw.NSIOServer 80 443 secret secret 127.0.0.1 -81 127.0.0.1 22 127.0.0.1 3389 >weblog.txt
where
1: -XX:+UseFastAccessorMethods -XX:+AggressiveOpts -XX:+UseBiasedLocking -XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=10
are settings for Java machine to make the memory usage be effectively used
2: -Duser.dir="C:\\Program Files (x86)\\TSplus\\Clients\\www"
The location of folder containing files of html5 gateway, also javascipt/html etc.
as example by usage of IIS it should look usually so
-Duser.dir="C:\\inetpub\\wwwroot"
3: 80 443 secret secret 127.0.0.1 -81 127.0.0.1 22 127.0.0.1 3389
1: 80 > telling the server to listen locally on all IP's on port 80 (0.0.0.0:80)
2: 443 > telling the server to listen locally on all IP's on port 443 (0.0.0.0:443)
3: standard password pair secret secret for cert.jks file for SSL certificate (if cert.jks is not in directory,the internal self signed certificate gets used)
4: 127.0.0.1 -81 > the negative number tells to the gateway to use internal Webserver instead Apache/IIS etc
5: 127.0.0.1 22 > tells to forward SSH traffic to port 22 on IP 127.0.0.1
6: 127.0.0.1 3389 > tells to forward RDP traffic to port 3389 on IP 127.0.0.1
Remember, all bound ports support all known protocols, also RDP, HTTP(S), SSL, SSH(Tsplus), Websockets, Flashpolicy(for Websockets via Flash)
---------------------------------------------------------------------------------------------
Now let's assume, you want to change the IP where you want to make your server listening. In this example the SSL traffic for HTTP(S) get's decrypted by Java engine and get's sent unencrypted to HTTP Webserver, that most likely used case.
com.jwts.socketjw.NSIOServer 192.168.1.50:80 443 secret secret 127.0.0.9 80 127.0.0.1 22 127.0.0.1 3389 >weblog.txt
1: 192.168.1.50:80 443 you force your server to bind to IP 192.168.1.50 on ports 80 and ports 443 (internally silently I bind it additionally on IP 127.0.0.1, because of compatibility reason, so IIS or Apache can not reuse this IP 127.0.0.1 on same ports too, so you should bind IIS/Apache to other IPs on 127.* area)
2: standard password pair secret secret for cert.jks file for SSL certificate
3: 127.0.0.9 80 > in case of usage of third web server like Apache/IIS etc it forwards in this example the HTTP traffic to port 80 on IP 127.0.0.9, also it assumes, the IIS/Apache is bound to IP 127.0.0.9:80 in this example
and https get decrypted to http and gets sent to 127.0.0.9:80 unencrypted.
So, as said, after saving the changes in runwebserver.but set read-only bit on this file to avoid rewriting by GUI.
--------------------------------------
Now other example. In this example the SSL traffic for HTTP(S) get's decrypted by Java engine and get's reencrypred sent to real HTTPS port Webserver, in some rare cases the IIS could check, if traffic arrives on it's SSL port.
This case is not CPU effective because of reencryption into SSL before forwarding the traffic.
com.jwts.socketjw.NSIOServer 192.168.1.50:80 443 secret secret 127.0.0.9 80:443 127.0.0.1 22 127.0.0.1 3389 >weblog.txt
also the part 127.0.0.9 80:443
tells to forward http traffic to port 127.0.0.9:80, and by https after decrypting to http, reencrypt again into https and send to ip 127.0.0.9:443
Also if traffic was thought to be SSL protected, it reencrypts decrypted HTTPS to HTTP again into HTTPS and send this traffic to 127.0.0.9:443 (remember, it costs unecessary CPU time to reencrypt packets, and should not be used to avoid slower transfer speed and unnecessary CPU load, only if not explicitely requested by internal third part webserver security requests)
The HTTP traffic can not be recognized before being decrypted, therefore such reencryption requested, becaue SSL is used not only by HTTPS, so HTTP can not be forwarded without being checked for protocol being protected by SSL..
PS: the webserver can be any world existing web server of your choice.. additionally it add's SSL support if third part webserver does not have own SSL support.