Fix loopback connections in IE10/IE11/Edge

[tresf]

Update: Domain networks have been fixed in 2.0.2 and higher via DNS workaround per b30beb7

Steps:

1. Run a custom batch script on each client:
https://gist.github.com/tresf/a57d6f342ca3886cb364fe153e34943f

Custom script no longer needed, via b30beb7

1. On the server, modify the JavaScript logic with the following fallback logic:

   qz.websocket.connect().then(function() {
     // We'll never get here in IE11/Edge on domain environment
   }).catch(function(ignore) {
     // IE11/Edge workaround
     console.warn("Could not connect to localhost, attempting localhost.qz.io instead.");
     // Note, to connect to locahost.qz.io using SSL/HTTPS, you NEED to re-run windows-keygen.js, see issue #6
     return qz.websocket.connect({ host: "localhost.qz.io" });
   }).catch(function(err) {
     // Apparently we couldn't use workaround 
     console.error(err);
   });

---

Currently, we use a brute-force method in IE to allow WebSocket communication by telling the computer to stop Automatically detect intranet network

This is a stop-gap which has adverse side-effects on a corporate LAN as it prompts for login credentials when accessing web resources.

Migrated from qzind/qz-print#67

[tresf]

This issues seems to have vanished in recent testing (perhaps an IE11 update patches this?)

• Tested on Windows 10 x64 and it seems to work regardless of these settings.
• Tested on Windows 7 x32 and it seems to work regardless of these settings.

[tresf]

Internet Options, Security, Local intranet, Sites button, Automatically detect intranet network

• Unchecked by default on a new user profile in Windows 7
• https://demo.qz.io blocked by default on a new user profile in Windows 7
• Unchecking Include all local (intranet) sites not listed in other zones fixes https://demo.qz.io

However...

• Checking Automatically detect intranet network also fixes https://demo.qz.io

So the highest compat? Always check Automatically detect intranet network

e.g.

... or

Note, http://localhost has not yet been tested.

[tresf]

Although a77a351 fixes connections for WORKGROUP computers, it does little to help with the domain environments due to the default Intranet Zone behavior on domain/corporate networks.

This puts IE and Edge in a bad state as the environments which tend to need IE support the most (controlled, domain style environments) suffer the worst IE support.

I've found an interesting work-around and depending on how the other OS's respond, it may be a good idea to leverage to deal with some potential future Chrome changes. The idea is pretty simple:

• Use a FQDN instead of localhost and point it back to localhost (or 127.0.0.1, ::1, etc). qz.websocket.connect({host: '<FQDN>...'});
• Change the just-in-time certificate to be marked for the FQDN rather than localhost.
• Force a manual DNS mapping on each platform to alias the FQDN properly (e.g. C:\Windows\System32\drivers\etc\hosts ...)

But this has serious scalibility problems... First, if Chrome does lock down localhost connections, this will only fix communication for domains that appear to be same-origin. e.g. Client websites may eventually suffer non-same-origin security warnings. Second it adds yet another hack to every OS. Last, writing fake DNS entries is frowned upon and can be observed as malware activity, at least on Windows.

So what's the lesser of all evils? Keep new functionality, restore old, or more hacks? @klabarge suggested making this configurable in the GUI, which is probably better than clobbering internet settings. Perhaps that's as far as we can get with this.

[tresf]

Added documentation via https://github.com/qzind/tray/wiki/FAQ#web-browsers

[tresf]

Per popular demand, we've added localhost.qz.io as a public address which will point back to 127.0.0.1.

This means qz.websocket.connect(...) can be modified to use the "Internet Zone" address to circumvent this "Intranet Zone" issue, however it will require a batch file be run on each workstation.

This has been documented here: #6 (comment)