Closed schonarth closed 2 days ago
Thanks for reporting the issue - we've been able to reproduce it. We're looking into what we can do to support this workflow, and will get back to you with further details as they emerge.
We've made changes to support this workflow and released them in Wallaby for VS Code 1.0.398
and Wallaby Core 1.0.1655
. There are a few things to be aware of.
When started, Wallaby will create a port forwarding entry (visible in the VS Code Ports
UI). This port will be private by default. Because of the way authentication is handled for private ports (requiring redirects) and the way the Wallaby UI view is hosted (in a VS Code webview, rather than a full browser instance), Wallaby UI cannot work inside VS Code with such a private port.
There are two ways to use the Wallaby UI with remote tunnels:
Change the port to public. While this will mean anyone with the URL can access the tunneled endpoint, it will not load / connect to Wallaby without the "secret" (a cryptographic value unique to the Wallaby session provided when launched from VS Code). Anyone attempting to abuse the URL without the secret can only cause a bit of extra load by requesting the Wallaby UI base assets (not your private data). The port can be changed from private to public by right-clicking on the entry in the Ports
UI and using Port Visibility
->Public
. If there are multiple mapped ports and you need to identify which one is Wallaby's, you can use the Wallaby.js: Show Wallaby Remote Port
command.
Use Wallaby UI in linked
mode. Using the Wallaby.js: Open in Browser
command will open the Wallaby UI in your browser, which will correctly navigate the authentication redirects, and the UI will load and function correctly.
Yes, after I updated to the latest releases and started Wallaby again in the remote environment, I saw a second shared port in VS Code. The first is the actual tunnel session, and then Wallaby at 55000. When I switched Wallaby's to public, the UI appeared here.
Thanks a lot!
Good to hear it's working for you! I've updated my answer above to cover the additional changes we've made to support this workflow, along with some additional information.
Issue description or question
Wallaby v2 runs fine locally, but when I'm on a remote machine via Microsoft's Remote - Tunnels VS Code extension, the new Wallaby tab stalls in the "connecting" state forever.
I have also tried running it externally, in browser mode, with the same outcome.
Both machines work fine when I run Wallaby locally.
Maybe it uses its own port that isn't being tunneled?
Wallaby diagnostics report
Below is my report when tunneling from the Mac into the Windows PC.