Extension proxy support

[CodeZombieCH]

Proxy support for Visual Studio Code has been introduced recently through environment variables/settings (see https://code.visualstudio.com/docs/setup/setup-overview#_proxy-server-support). As an extension developer I would like to use these settings when requesting resources from the internet. My current implementation fails for users using a proxy.

What is the recommended way for an extension to use a proxy?

I could not find a vscode API that exposes methods to make requests using a proxy other than access to the proxy settings (workspace.getConfiguration()) and implementing everything on my own. Looking at the Visual Studio Code code base I identified the code that adds support for proxies, but copy&paste it into my extension would result in duplicated and potentially outdated code, which is something I want to avoid whenever possible. As I am probably not the only extension developer accessing the internet, I would like to hear your opinion on this issue. Any feedback would be greatly appreciated.

[jrieken]

-1 for adding this for to the API but +1 for extracting our code into a node-module. @joaomoreno how feasible is that? how much code do we add on top of other node-modules?

[joaomoreno]

It's thin.

[jrieken]

I leaving it with you then ;-)

[CodeZombieCH]

A node package sounds like a cool solution. Let me know when it's ready so I can test it and provide feedback.

[joaomoreno]

We're going with a different proxy solution in the future, skipping this.

[CodeZombieCH]

Do you have any details about that future solution?

[joaomoreno]

Actually, I might've closed this too eagerly.

We're going with using Chrome's network stack for everything. So you're a bit busted. The only way out is exposing an API for making network requests. I'll leave this open for that.

[tebeco]

@joaomoreno any news from April ? times to times, We have to set our password in clear so far in the settings json file in order to update OmniSharp

This is insane and quite critical Everybody tries to point someone else team and it really hurt lots of people using VsCode in companies

[tebeco]

Do i need to ping more contributor to VsCode in order to get more feedback on it ?

[gsemet]

+1

[genenorton]

This is super annoying... It makes extensions mostly useless in corporate world. which makes it unlikely that I'll use vs code at work..... back to notepad++ i guess.....

++1

[tebeco]

+1 VsCode need to proxy an API to extensions that provide a kind of “fetch” api but will read proxy settings if necessary especially when on windows this settings is ALREADY used by vscode itself

[tebeco]

As a reminder in corporate having to set the password in clear is not ok at all same goes for HTTP_PROXY no go

and CNTLM is a crap on windows, ever tried npm install behind ? nop

[PlanetWilson]

This is getting really painful. As VSCode gains in popularity and is the de-facto standard for Office365 dev these days it is critical to get this working.

[vicpara]

Terminate Visual Studio Code , go in terminal and run code --ignore-certificate-errors to start it ignoring ssl certificates. This solved my problem.

[jeannich]

The solution proposed by @vicpara above did not work for me.

Instead I am using this workaround: code --proxy-server="http=proxy:8080;https=proxy:8080;ftp=proxy:8080"

[tebeco]

of course it does not work :D ignoring ssl certificate is just if on top of having a proxy, your proxy actually rewrite ssl with it own certificate and that certificate is a self signed certificate

vscode is still lacking the ability to check

hkcu:/software/microsoft/windows/currentversion/internet settings

then goes for keys like AutoConfigUrl for PAC script ProxyServer for http proxy

in fact all the data are here hkcu:/software/microsoft/windows/currentversion/internet settings/Connections/DefaultConnectionSettings need to check that bitarray with : array[8] <== this is a bit mask and this tells you what to read (what is enabled or not)

[tebeco]

this is what user on windows expect in fact you should not do trick running vsCode when the soft it self build target that windows could actually process these already existing values

[omniproc]

I agree with tebeco. The system default proxy should be used if nothing else was configured. Still it's probably a good thing to have overrides in the workspace settings so devs working on the same project from the same environment can simply share the correct config.

Yet it seems like there are many things missing. E.g. "proxy" is not the only thing that needs to be implemented for proper proxy support. The exclusion / bypass list of the OS also has to be correctly handled and we need a override setting for that as well.

I'm aware of the chromium switches but they do not what the other two options do:

• workspace setting options: enable quick sharing of a workspace config
• system os defaults enable a great out-of-box experiance

Also I found the chromium parameters not to work all the time. In my case --proxy-server="myproxy:port" is ignored. It works if I set it in the workspace settings but then the --proxy-bypass-list parameter is ignored.

[sit-md]

I am running the latest VS Code version on macOS Sierra and I'm seeing a ECONNREFUSED when trying to fetch from "https://schemastore.azurewebsites.net/schemas/json/tsconfig.json" whenever I open my tsconfig.json even though the proxy settings are definitely correct. When I call the failing address in a Chrome instance it opens perfectly fine. I was testing using all the methods there are:

• starting VS Code with parameters
• setting the http.proxy, etc. settings within VS Code
• setting environment variables HTTP_PROXY and HTTPS_PROXY

My findings:

1. on macOS the parameters at startup are having absolutely no effect on the behavior. VS Code cannot even resolve the URL.

2. Setting http.proxy inside of VS Code or using the env variables has the same effect (even though I didn't test what takes precedence in the end)

3. The ECONNREFUSED seems to come from our company proxy server. I could rule out that it is a authentication problem by specifying my credentials It came from our internal proxy server indeed due to the fact that I provided the AD domain in front of the user which lead to an instant bounce instead of going through the configured rules. Leaving out the AD domain I got 407's smacked in my face. After hours of debugging the issue with a guy from the proxy department we finally found out that there's something off within the proxy settings. The fallback from (C)NTLM to Basic Auth did only work if the client supported this. Now the config is changed in a way that if the client asks for Basic Auth the proxy won't first try to use NTLM anyway but right away Basic Auth. Nevertheless: specifying credentials in plain text and disabling SSL verification is a more than ugly way to work around this problem (which can't be a permanent solution anyway as pointed out by @tebeco)

Considering that these issues have been going on for almost 2 years now (look at the ticket creation date!) it is definitely about time to solve them for good. @joaomoreno considering that this also happens with the TypeScript extension is very sad to see. Microsoft should have an eager interest in supporting corporate environments. The lack of updates and support from the VS Code team in this ticket - sorry to say - though unfortunately shows the opposite.

[joshsackos]

Cannot install Particle Workbench dependencies behind a proxy at work. This is an old ticket, if Microsoft actually wants people to use VS Code, then they should fix this. Companies should really look at an alternative to VS Code due to this limitation. All corporate users behind a proxy will not be able to use the company's VS Code extensions that need to download external content, thus rendering the company's efforts useless, and then the customer will probably find an alternative product that provides decent tools, which will reduce the company's profits. Have a merry Christmas everyone! :)

[gsemet]

If you define HTTP_PROXY and HTTPS_PROXY, extension can « see » the outer world. It I sad to see this support is not straight but as least it does the job. And you may have to hardcore your proxy password in an env car, which is pretty bad...

[joshsackos]

No, setting HTTP_PROXY and HTTPS_PROXY does not solve the issue.

[gsemet]

I do have them, with lowercase as well, in my use env var, and it works

[joshsackos]

Windows environment variables are not case sensitive, so you can only have one variable for each. Glad that you have a solution that works for you. Obviously it is not a universal solution though. Best of luck to you, happy holidays!

[joaomoreno]

Hey guys you might wanna follow https://github.com/Microsoft/vscode/issues/60773

There's been some great exploration development by @chrmarti: https://github.com/Microsoft/vscode/issues/64202

[nschonni]

It looks like this was included with 1.31. It doesn't support NO_PROXY, but I'm opening a separate issue for that

[SetTrend]

@m451: I suggest to utilize the system default proxy, too.

The organization I'm currently working for is using NTLM authentication with their proxy. This is causing HTTP 407 errors when using environment variables HTTP_PROXY/HTTPS_PROXY.

[solarjoe]

I found this issue https://github.com/Microsoft/vscode/issues/38888

They mention that supplying the proxy parameters on the command line works, even if setting it in VS Code doesn't. And this works for me. Still not beautiful, as the password is clear text, but for the other options (environment variables, settings.json) this would also be the case.

So I added this to my desktop shortcut and the two popups are gone:

"C:\Path\To\Code.exe" --proxy-server=http://user:password@123.123.123.123:8080

[tebeco]

pretty sure the password in the cleary not something anybody want here.

I would love VsCode to know if it's possible that VsCode offers an Api to use the same proxy that the updater use. as long as i know the updater has no issue. the main issue is that i'm not sure NodeJs can handle Ntlm, so it would need VsCode to spawn a process to proxify request properly then the settings would just be "use system proxy" (like most browser today i believe), that would check for HTTP(S)_PROXY / NO_PROXY Pac script etc ... well standard system Proxy

as vscode builds are already Platform specific i guess platform specific feature is something already possible ?

[chrmarti]

For downloading extensions and VS Code updates we are using Chromium's cross-platform support for proxies. That looks up the proxy configuration in the OS.

For extensions (which run in a separate process that does not have Chromium's network library available) we are using an Electron API to look up the proxy configuration from the OS. That is cross-platform, but it does not support authentication.

[tebeco]

thx a lot @chrmarti for the insight on how it work and what's available with electron/chromium. i had no idea of this difference and big limitation :(

As a general pattern with chromium/electron we often see dedicated child process per tasks (Network/GPU/ ...)

Having one dedicated to forward request using Platform specific API without the limit of Electron API (as we seems to all agree that Electron API is too limited for that issue, and require more code to have both proxy working and security / user handling :

• no password in clear text
• use Os settings
• respect entreprise GPO (pac script)
• user does not have to change it password every time she/he change AD login

i think the worst part is the account being locked when the AD password changed but you forget it in vscode, once you max out the attempt (old password) of login the AD Account is locked

As explicit/auth proxy is a disaster in lots of company that should replaced by implicit proxy, lots of users are still suffering from it today :(

I'm just looking for a secure way to avoid clear text pas in vscode

[chrmarti]

Extensions generally use Node.js' http or https modules (directly or through a module like request). To get extensions to support proxies using the OS' proxy settings we patch the http and https modules. It would be hard to get all extensions to use some custom API when they are used to (and already use) Node's API.

PAC scripts should work. Just authentication does not work. Filed: https://github.com/electron/electron/issues/20215

[SetTrend]

Would you suggest to cross-reference to a (new) NodeJS issue? I guess, NodeJS would want to support enterprise environments, too.

[sit-md]

Just authentication does not work.

Which is key in enterprise environments. Every bigger company needs it but it is almost always one of the last things being implemented because the developers/product owners hate the effort necessary to make it work well and with all the bells and whistles that can be found in enterprise environments. Understandable from my perspective but also very frustrating - every time I run into these issues.

[chrmarti]

Node.js issue: https://github.com/nodejs/node/issues/15620. They don't seem to be keen on getting proxy support in their core.

[meustrus]

Ever since proxy support for extensions was enabled, my extensions stopped being able to reach the internet. Every attempt results in a certificate authentication error.

I'm guessing that my problem is that the patch for https does not also pick up the OS-level certificate store. This appears to be what the setting http.systemCertificates is for. Does that setting also patch https for extensions?

For now, turning off the patch for extensions with "http.proxySupport": "off" fixes my problem because the network allows some requests through without using the PAC-file based proxy that uses the corporate root CA. That won't solve the problem for everyone, though. microsoft/vscode-azurefunctions#1429 may be caused by a transparent proxy that does require the corporate root CA.

[chrmarti]

I'm guessing that my problem is that the patch for https does not also pick up the OS-level certificate store. This appears to be what the setting http.systemCertificates is for. Does that setting also patch https for extensions?

Yes, http.systemCertificates is specifically supporting the https module for extensions. Could you open a new issue, so we can look into why this doesn't work in your case?

[SylvainMartel]

Ugh, 3 years and not close to a solution. I guess I should tell management to forget about using VS Code. We're behind an authentication proxy and as soon as an extension tries to download something, like the language server, it fails, so we cannot use them.

[GigiusB]

I had a progress with this which I believe may be related: after launching "code --verbose" I could see errors like the following:

ERROR:cert_verify_proc_nss.cc(969)] CERT_PKIXVerifyCert for update.code.visualstudio.com

I then followed the instructions at Linux Cert Management in order to add our corporate CA certificate as follows:

certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n ybs -i $CA_CERT

After relaunching VSCode everything seems working!

[orthoxerox]

For those visiting this from a search engine, to make extensions like C# work via an https proxy with authentication, right now you need the following:

1. You need your proxy with username and password in settings.json: "http.proxy": "https://user:pwd@host:port" (without it you will get error 407)
2. You need to install win-ca extension from ukoloff
3. You need "win-ca": "append" in settings.json (without it you will get "Error: self signed certificate in certificate chain")
4. Don't put anything else proxy or http-related in settings.json

I tested this both in 1.46.1 and 1.48.0 (with auth.js fix)

[tebeco]

This look like it would be more sustainable to have all of this baked within VsCode, and not at the full charge of extensions developer, and at the cost of consumer security.

Somehow, having an API in VsCode return an HttpClient already setup, and supporting POSSIBLE NTLMv2 / Kerberos look like something acheivable in order to use VsCode safetly.

The equivalent in C# would look like:

public HttpClient GetMeSomethingReady()
{
  var proxyHttpClientHandler = new HttpClientHandler()
  {
    Proxy = new WebProxy("http://FROM_THE_SETTING_NO_CREDENTIALS")
    {
      Credentials = CredentialCache.DefaultNetworkCredentials
    },
    SslProtocols = SslProtocols.Tls13 | SslProtocols.Tls12 | SslProtocols.Tls11 | SslProtocols.Tls,
    UseProxy = true
  };

  return new HttpClient(proxyHttpClientHandler);

then extensions developers would do something like

var httpClient = GetMeSomethingReady();
httpClient.Get(url)

If they want to do everything from scratch ... why not, but it look like this should be

• out of the box
• 0 extensions required
• no password nowhere, as the user is already logged, and already has NTLMv2 / Kerberos ticket
• use the User Certificate Store on windows build (that's the standard)
• No env var as this would require special script to run VS not to polute shell session or user session

[chrmarti]

@orthoxerox Part of win-ca is already built-in, you shouldn't need to install it separately.

[orthoxerox]

@chrmarti I shouldn't, but I had to. "http.systemCertificates": true is the default setting, but it only allows VSCode to download extensions without complaining about self-signed certs, not the extensions to download their dependencies.

[southwood]

Here is a workaround that enables extensions to be used in a devcontainer while a mitm solution (such as zscaler) is deployed to your network.

In devcontainer.json:

"remoteEnv": {
    "NODE_EXTRA_CA_CERTS": "<PROVIDE_YOUR_TRUSTED_ROOT_CA_CERT_HERE>.crt"
},
"postCreateCommand": "sed -i -e 's/this\\.strictSSL=/this\\.strictSSL=false\\&\\&/g' $(find ~ -name *HostAgent.js)",

I think root cause is that remoteExtensionHostAgent.js ignores all the existing settings.json files and overrides local container's npm/node configuration by default. Another way to achieve this is to configure http.proxyStringSSL in your local settings.json and then drop that into every subdirectory of the extension runtime find ~ -type d | xargs -I {} cp .vscode/settings.json {}. If anyone knows which specific folder's settings.json is used by remoteExtensionHostAgent.js, that would be a better option than using sed to edit the minified js.

[Glutnix]

Workaround for vscode.github-authentication giving a HTTP error 407 when receiving the authentication token from a browser:

In VSCode Settings, you can set http.proxy to http://username:PASSWORD@your-proxy-ip:port (or https if required) before authenticating AND REMOVE IT once you verify your username appears in the Accounts button on the Activity Bar. Plugins like GitLens and Settings Sync don't need to use the proxy once you've done this.

[Szaboadrii22]

In VSCode Settings, you can set http.proxy to http://username:PASSWORD@your-proxy-ip:port

[Szaboadrii22]

Extension proxy support #12588

[joewood]

One alternative to the suggestion of creating a VSCode fetch API for extensions would be to use the VSCode host as a proxy. VS Code already supports PAC files and NTLM/GSS corporate proxy authentication. Using this networking stack it could expose a port to the extensions like CNTLM. This could be exposed in the form of http_proxy env variables (so no change would be required there). Network requests would then pass through VS Code.

This feels like the simplest approach as it requires no change to extensions (continue to use http_proxy), the code for port forwarding is already in present.

[tebeco]

that's why multiple users in that thread are asking for since 2016/2017

it seems to be most logical one in order to have something uniform and also consistent with the OS