Proxy handled differently when adding new organization

[schrej]

• Operating System:
  • Windows
  • Linux/Ubuntu
  • macOS
    I've tested it with v2.5.0-beta as well as v2.3.82.

It's me and my strict proxy environment again.

We encountered a new issue: When adding a new organization the client tries to reach the url to check if it's an actual Zulip instance. This only works only with a specific, open proxy that not everyone has access to within our network.
Interestingly, once the org is added the other proxies work fine as well. It's only the initial check that doesn't work properly.

What's the difference between that check and the tab with the webview containing Zulip? I've looked at the code but haven't found it yet.
If there is an obvious difference, it might be possible to fix this, so the proxies get applied the same way to everything.

[kanishk98]

@zulipbot claim

[kanishk98]

@schrej I've been trying to figure this out but I don't think there's much I can do without your proxy env. :)
Can you log the response status code when the app makes a request to the .ogg file?

Specifically, in domain-util.js here,

return new Promise((resolve, reject) => {
	request(checkDomain, (error, response) => {
	console.log(response.statusCode);
	// If the domain contains following strings we just bypass the server

I'm guessing that this is because of problems in our validation logic. It'd be great if you could confirm that in your environment.

[schrej]

Ok, the issue here seems to be that the proxy that isn't working requires authentication. The working one doesn't.
Unfortunately I'm not 100% sure how the proxy authentication works usually, afaik it uses the Windows login somehow. The difference here might be that for the WebView a full chrome tab is used but for the connectivity check it's nodejs that does the request.

Error: tunneling socket could not be established, statusCode=407
  at ClientRequest.onConnect (C:\Users\A33438080\D…-agent\index.js:166)

I'll investigate a bit more once I have some time to spare and will update this issue when I find something.

[kanishk98]

I did some digging and it looks like Atom also suffers from a similar problem, mostly because handling proxy auth in npm is troublesome.

Anyway, based on what worked for other people online, I suggest running:

$ npm config set https-proxy http://<username>:<password>@proxyaddress.com:[Port]                                                                            
$ npm config set https-proxy http://<username>:<password>@proxyaddress.com:[Port]
$ npm config set strict-ssl false

It might be easier to place them in ~/.npmrc, but you get the idea. I'm guessing you'll have to use some combination of the above, depending on your configuration.

[schrej]

Apparently our normal proxies are using NTLM for authentication, which is quite common. While the WebView does support it apparently, as chrome does as well, the authentication works fine for already added organizations. Nodejs on the other hand doesn't support it natively and therefore doesn't authenticate against the proxy and gets rejected.

I'm not sure it would be worth adding support for NTLM in the nodejs part of zulip desktop. In our case there is a workaround available and also utilities like px can solve this issue.

[kanishk98]

Okay, that's pretty helpful. Thanks @schrej!

I'm not sure it would be worth adding support for NTLM in the nodejs part of zulip desktop.

@akashnimare should be able to answer this better, and I'd be glad to take this up if we do decide on implementing support for NLTM.

Until further discussion, it's best if I abandon the issue.
@zulipbot abandon

[akashnimare]

Not familiar with the NLTM proxy, gotta look into it.

[kanishk98]

Abandoning the issue until we're clear on NLTM.

@zulipbot abandon

[abhigyank]

@schrej I am not familiar with NLTM proxy, but can you try this (some nltm modules seems to get it working by doing this) -
Below this line add two parameters -

username: 'username',
password: 'password'

This should probably authenticate the domain addition requests.

[schrej]

One of the core features with NTLM is, that it uses the windows credentials automatically. Also, request doesn't support NTLM (request/request#808).
Adding the request options doesn't help.

[zulipbot]

Hello @kanishk98, you have been unassigned from this issue because you have not updated this issue or any referenced pull requests for over 14 days.

You can reclaim this issue or claim any other issue by commenting @zulipbot claim on that issue.

Thanks for your contributions, and hope to see you again soon!