Chrome permits access to ws://127.0.0.1 from https apps. I believe it's also making its way to Firefox, which is currently http only. Other browsers (ie/edge/safari) don't even follow this exception for http yet.
Interesting. My impression from the above bug was that they explicitly decided against keeping it open. If they reversed their position, that would be good news.
Could you give a link where this is discussed? I see crbug.com/378566 mentioned in another comment, but there doesn't seem to be a decision in there, apart from general acknowledgement that the use-case exists.
While a huge pain the ass, it could be possible for your local app server to create a [bridged] virtual host network that routes locally for your server. It utterly ridiculous to resort to this method though. Does anyone else have an idea of a workaround?
That wouldn't solve the problem though. The browser would still block your bridged connection if it isn't https or wss.
At which point you again need a domain for your virtual IP, a certificate for your domain and a private key for the certificate on the device, which will probably cause your certificate to be reported as a vulnerability and revoked.
> Fortunately, modern browsers consider “http://127.0.0.1:8000/" to be a “potentially trustworthy” URL . [...] WebSockets don’t get this treatment for either name.
It's good they at least added an exception for (verifyable) localhost access - but then why is the exception only given for HTTP? There seems to be a deliberate restriction that websockets are excluded.
I find this kind of strange and frustrating as the websockets wire protocal actually contains more protections against accessing vulnerable services than HTTP. So without this exception, this leaves you no way at all to connect to a local service via websockets.
I've found this ticket for chome[1] where apparently the rationale is that they want to move people to their own IPC messaging mechanism. However, this is chome only and requires you to register a chrome extension.
So if I get this right, this still leaves no standard way to have asynchronous communication with a local process.
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=418482