BrowserStack configuration behind a proxy is not clear about digdug HOT 24 CLOSED

It'd be nice if someone acknowledged this issue. I aim to spend time next week debugging in that environment to identify if it is a config issue or a library issue

from digdug.

@lbod i might guess that nobody else has tried using using browserstack behind a proxy and may not be in a position to spend the time to setup an environment to try this so we are not able to acknowledge the issue. it looks like you may be breaking new ground so forge ahead and let us know what you find.

from digdug.

@neonstalwart I figured as much as no one else has reported this & there's been no meaningful replies on SO; it's fair to say there are no corporate users using intern against browserstack.

However, does that configuration above look correct?
I spent most of the day debugging this comparing against a standard wd.js test which works (https://www.browserstack.com/automate/node) and not made much headway. I suppose dojo/request/node is another layer in the way too; digdug may not be the place this issue belongs

I'll setup privoxy on my home laptop to try reproduce as I can't justify spending time on this at work

from digdug.

@lbod it doesn't quite look correct to me since i would assume that your proxy might need a username and password. all the proxy config is extracted from proxy : 'http://<myproxyip>:<myproxyport>' (see

my suggestion would be to initially cut out intern/digdug completely and just download the browserstack local executable yourself, figure out which arguments need to be passed to that executable in order for everything to work with the proxy, and then work backwards from there to figure out what you need in your tunnel config in order for _makeArgs to produce the same arguments to the executable. at that point, it still may not work but then you will have eliminated your config as the cause of the issue.

from digdug.

@neonstalwart thanks, at the moment we're whitelisting ip's, so no usr/pwd needed but I can add a dummy usr/pwd to make sure there's no funky logic relying on this.

I did see generated urls of the form http://"browserstack user name":"browserstack auth key"@hub.browserstack.com:4444/wd/hub/session in Server.createHttpRequest() which didn't look right., also tried adding the proxy to the kwArgs object in there.
I'll keep digging

from digdug.

I undid any hacks I'd made and checked makeArgs which is producing the correct arguments to start BrowserStackLocal (sniffing tcp traffic I see successful communication to and from hub.browserstack.com) however from somewhere I'm getting dns resolution issues for hub.browserstack.com. We can't resolve external DNS from our company PC's, however I'd expect those requests to be using the proxy. e.g. :

Error: [POST http://(redacted)@hub.browserstack.com:4444/wd/hub/session] getaddrinfo ENOTFOUND
Error: getaddrinfo ENOTFOUND
  at errnoException  <dns.js:37:11>
  at Object.onanswer [as oncomplete]  <dns.js:124:16>
FATAL ERROR

Error: [POST http://(redacted)@hub.browserstack.com:4444/wd/hub/session] getaddrinfo ENOTFOUND
Error: getaddrinfo ENOTFOUND
  at errnoException  <dns.js:37:11>
  at Object.onanswer [as oncomplete]  <dns.js:124:16>

from digdug.

@neonstalwart any advice on where I can stick some breakpoints to see where these requests are coming from to trace it back?
e.g. I found pathname: '/wd/hub/' but could only see a reference to that in https://github.com/theintern/digdug/blob/master/SauceLabsTunnel.js#L313

from digdug.

Just to note I believe dojo/request is the cause, I raised this https://bugs.dojotoolkit.org/ticket/18424 but not had any feedback.
I was able to get that example change working from home using my own proxy but haven't been able to do correctly with my corporate work proxy.

This is also relevant to #17

You could consider this as an upstream bug but seeing intern is part of the Dojo foundation it seems wise to keep both these issues open

from digdug.

Any updates on this issue? Still relevant?

from digdug.

I suspect it's still relevant to others, not to me or the company I work for as we switched to other various testing libraries which didn't have this issue.
Thanks for the ping though it's way too late and just a cleanup of old issues.

from digdug.

+1

It's an issue for me, unless there is something else interfering that I'm not aware of.

from digdug.

Hi @jason0x43 ! Crazy I opened this 4 years ago, sorry if this is a long one..
I had a try again through our proxies the last week as we're evaluating some testing libraries for a new project.

I tried out the typescript/backbone example, upgraded to the latest to make sure and as I suspected it still didn't support CONNECT tunnelling proxies. Intern/dojo's changed a lot since I last looked so there was a bit of digging around first and getting support from the network team in work. dojo's node.js provider just doesn't support it.

Eventually I hacked something working and wanted your thoughts the best way to do this. I used https://www.npmjs.com/package/global-tunnel-ng and loaded it as a plugin to see if I could bootstrap the process. Something like :

    "browser": {
        "loader": "systemjs",
        "plugins": { "script": "src/config.js", "useLoader": true }
    },
    "node": {
        "plugins": {"script" : "src_node/global-tunnel.js"}
    }

In that plugin I added the initialise script, something like:

var tunnel = require('global-tunnel-ng');
tunnel.initialize({
    host: 'xxx.xxx.xxx.xxx',
    port: xxxx,
    connect: "both",
    protocol: "http:"
});
module.exports = tunnel;

It got further, (can't remember if it was a 4xx or a 5xx and if it was the BS local binary trying to download) but I still had the proxy config in the tunnel config in intern.json.

Removed that and the next error was the browserstack local tunnel binary args (because I'd removed the tunnel proxy property). So I hacked node_modules and just hardcoded the proxy at https://github.com/theintern/digdug/blob/master/src/BrowserStackTunnel.ts#L174

Hey presto, connectivity and the full local unit/functional suite ran. I didn't have time to debug and will look tomorrow why the difference.

Any thoughts on how I could inject that proxy config just for the BS local binary? I was sure there's another issue about the same thing.
I still think there's mileage in it before I discount it as something we use, I also realise I need to understand the new architecture more and maybe loaders but it seems we're not far from it working.

I could try and contribute something back on this as I've learned a bit more about how the hop-by-hop goes. I wouldn't want to be just copying code from that global-tunnel-ng library though but this is an upstream dependency issue with dojo. It might be nice to be able to swap out that request provider dependency to another.

from digdug.

Hi! Wow, yeah, this one's been around for a while. :)

What did your working BS tunnel end up looking like? If we can figure out specifically what handles the problem, we can see about making it a general option for tunnels.

Also, have you tried the newest Dig Dug yet? We removed all the @dojo dependencies from Intern and its projects because they were causing frequent typing issues with Dojo itself (which uses Intern for testing). The current release uses request from @theintern/common, which uses axios behind the scenes. We haven't really exercised its proxying capabilities much yet, but it may behave a bit better.

from digdug.

Quick reply thanks!

What did your working BS tunnel end up looking like?

It was just removing the proxy property

configs : {
  "bsproxy" : {
    "tunnel" : "browserstack",
     "environments" : {
           "browserName" : "chrome"            
      }
  }

Also, have you tried the newest Dig Dug yet?

Maybe I'm not understanding, I had seen the references to axios and seen the TS docs that say it mirrors dojo's request API. At first look it it also seemed to have the same lack of support.

But.. Dig Dug is a dependency of intern and I'm using 4.2.4, so Dig Dug is 2.1.2.

from digdug.

Hi @jason0x43 I wasn't sure if I was to get back to you with more info?

https://github.com/theintern/digdug/blob/master/src/Tunnel.ts#L441 the "bsproxy" config I have above won't have that proxy config as it's removed. The binary binary process is spawned with the tunnel args and obviously not going to be bootstrapped with the node.js http/https API global either (from global-tunnel-ng).

So at the moment I need to be able to separately set the binary proxy arguments. The browserstack binary client can obviously work with CONNECT proxies.

Me hardcoding the proxy args into the node_modules package JS (BrowserStackTunnel.js) looked like

    if (this.proxy) {
      const proxy = parseUrl(this.proxy);

      proxy.hostname && args.push('-proxyHost', proxy.hostname);
      proxy.port && args.push('-proxyPort', proxy.port);

      if (proxy.auth) {
        const auth = proxy.auth.split(':');
        args.push('-proxyUser', auth[0], '-proxyPass', auth[1]);
      }
      /*else {
				proxy.username && args.push('-proxyUser', proxy.username);
				proxy.password && args.push('-proxyPass', proxy.password);
			}*/
    }
    // ME HARDCODING
    args.push('-proxyHost', "http://xxx.xxx.xxx.xxx");
    args.push('-proxyPort', 8080)

Does that make sense?

from digdug.

Hmmm..I'm not sure I understand the core issue.

There are at least two network connections involved with Dig Dug tunnels -- Dig Dug has to connect to a server to download the tunnel binary, and the tunnel binary needs to connect to a remote server. Dig Dug assumes that if a proxy is required, both of these connections will use it for outgoing connections.

In your fix above, it looks like you're overriding the proxy config that's passed to the BS executable. Is the issue that the BS executable needs to use a different proxy than the one Dig Dug uses to download the executable (maybe Dig Dug doesn't need one but BS does?), or that the existing proxy config isn't being passed properly to the BS executable, or something else entirely?

from digdug.

Yes, sorry it looks like I'm not explaining this well at all.

Effectively I want to separately configure proxy args for the BS executable.

Because I'm bootstrapping in this global-tunnel-ng module (and setting proxy configuration there) I don't need any Tunnel configuration set for proxy. However I do still need those arguments to be set on the BS executable.

I have no idea if global-tunnel-ng is even a good idea, I want to drive a large suite of tests through it to see if there's any weird stuff, latency etc. However it is the only option we have behind a CONNECT tunneling proxy server because dojo's request/node or axios doesn't support it.

from digdug.

Ok. What if we add a a tunnelProxy option to the tunnel options that will apply to the tunnel executable specifically. So, from intern you'd end up doing something like:

{
  "tunnelOptions": {
    "tunnelProxy": "http://xxx.xxx.xxx.xxx:8080"
  }
}

The tunnel classes can then use tunnelProxy if it exists and fallback to proxy by default. Setting tunnelProxy to null could disable the proxy for the tunnel while allowing it to be used by dig dug, if necessary.

from digdug.

Yes that's perfect. Thanks!

Do you want me to PR it if it saves you time? You said you were busy and I completely understand that

from digdug.

Go ahead and PR it.

from digdug.

Hi @jason0x43 I've been away from work the last week but made the change locally. Will be able to test when I get back, however..
I'm uncomfortable adding this for all tunnels because I won't be able to test them and also because the other tunnels are very much different.

It makes sense to only add a property to the BrowserStackTunnel? (though I do understand that's not ideal).
#65 is possibly asking a similar thing for the selenium tunnel, if they could confirm it's a connect proxy in use then maybe this workaround will work for them if they were willing to commit/test too.

from digdug.

I'm not sure #65 is related to this issue; in that case, Dig Dug is unable to download files through a proxy, implying the base proxy property isn't working at all. In your case you need the regular tunnel downloads and the BrowserStack tunnel executable to use different proxy settings.

Regarding adding the setting for all tunnels, the idea would be to add the tunnelProxy setting to Tunnel.ts, and update tunnels to actually use it separately. So for now, only BrowserStackTunnel would actually use the setting; the other tunnel classes would simply ignore it.

from digdug.

@jason0x43 apologies for my delay. It's a tiny commit but had to keep back and forth testing at work and then was lazy.
Originally I thought the doc should remain in the browserstack api properties as it would seem misleading to others but I've added as you asked.

from digdug.

Closing this as resolved by f504f84

from digdug.