Connect to localhost and not 127.0.0.1 (support for WSL)

[MatthewPinheiro]

I use VSCode through WSL, and right now the SN Utils browser extension can't connect to ScriptSync when its running on a WSL VSCode instance without workarounds.

Basically, when ScriptSync sets up a websocket server, it implicitly sets the host to :: (the IPv6 unspecified host). However, this line in SN Utils tries to connect to the server at 127.0.0.1 which is an IPv4 address. On native Windows, this usually ends up working anyway because Windows creates a server on both IPv6 and IPv4 addresses. But in environments such as WSL where dual IP doesn't work, the server only ends up on the IPv6 address. So when SN Utils attempts to connect to 127.0.0.1, it fails because no ScriptSync server exists in the IPv4 address space.

There's a really easy fix to this though. That line just needs to be changed from 127.0.0.1:1978 to localhost:1978. This is an alias for both loopback addresses (e.g. 127.0.0.1 and ::1) so the connection will work no matter which address it ends up on.

[arnoudkooi]

I'm pretty sure I'm using the IP instead of the localhost because that had issues as well.
This change would also need to be applied in the manifest file, and that would trigger disabling SN Utils and a prompt about the localhost permission. I want to prevent that.

Is what is suggested here an option, or at least a setting in the WSL environment that makes sure the server is accessible via the IP address?

[MatthewPinheiro]

I can definitely see why manifest updates too often would not be great if it means disabling the browser extension each time!

Is there perhaps a future release you have planned set aside for those, e.g. so you batch manifest updates once a year or something? My team and I already have proxying mechanisms in place to workaround this issue but I think WSL is increasing quite a bit in popularity (5x increase as primary dev OS from 2021 to 2023) so I think this may become a bigger issue for more people in future.

Another alternative solution (which may also have value outside of this) would be on the ScriptSync side, where you could add host as a modifiable VSCode setting. This way, users could explicitly set an IPv4 host themselves?

[arnoudkooi]

Your alternative would require a wildcard permission in the manifest file, so not an ideal solution either.

Could you share the workaround you found?

[MatthewPinheiro]

Sure, the workaround is just to create a proxy on the Windows side to forward traffic from IPv4 over to IPv6 for the relevant port. You can do this with the following command in PowerShell:

netsh interface portproxy add v4tov6 listenaddress=127.0.0.1 listenport=1978 connectaddress=::1 connectport=1978

[MatthewPinheiro]

As for the alternative, to be clear, that would not be a change to SN Utils. It would be a change to ScriptSync only, to expose its Host configuration as a VSCode setting, so no changes to the manifest on SN Utils at all. This would allow the user to override the default :: that the ScriptSync server listens on to instead be 127.0.0.1, which is what the chrome extension is expecting to connect to anyway. This would also have other advantages, such as allowing the user to lock the server down to the loopback IP for network security (right now, anyone else on the network can connect to the ScriptSync server, not just the user).

[arnoudkooi]

Im ok to add an explicit host like so:
wss = new WebSocket.Server({ port: 1978 , host : '127.0.0.1'});

How would you suggest only allowing the loopback IP?

[MatthewPinheiro]

I’d suggest it by doing this:

// Node will continue binding on ‘::’ if undefined
const host = vscode.workspace.getConfiguration('sn-scriptsync').get('host');
wss = new WebSocket.Server({ port: 1978 , host });

This way, there’s no change to the behavior of the server as it is now, unless the user goes into the extension settings and puts in a value such as “127.0.0.1” (the IPv4 loopback IP), which would both lock down access to the user’s PC only and also solve the single IP stack issue in WSL.

I can make a PR sometime this evening (EDT) to do so if you agree?

[arnoudkooi]

I don't see the need for a setting, as it needs to be 127.0.0.1 to work.
Neither do I see how this would lock down to only localhost traffic?
Note that I have limited traffic to only one concurrent connection and disallow origin http*

[MatthewPinheiro]

Ah, I see, apologies if I misunderstood initially. In that case, then hardcoding the host to 127.0.0.1 as in your code snippet would be sufficient to only allow traffic from the user's own device and would solve the WSL issue.

If you're asking why listening on 127.0.0.1 forces a server to only accept traffic from the same device as the server, then that's because 127.0.0.1 is already a loopback address, meaning it doesn't appear on the network. It's an IP that only ever refers to the local device, and means the server isn't reachable from anywhere other than that device (and apologies if I'm still misunderstanding the question haha).

[arnoudkooi]

2.7.3 with this update is published. Hope that fixes it!

[MatthewPinheiro]

Just tested it, fixed! Thank you!