Proxy Env-Variable not inheriting from VSCode

[cyacedev]

First, thanks for your hard work. I have been testing the extension the last few weeks, and it works extremely well. Sadly, my company uses an authenticated proxy and therefore limits these network calls that your plugin is making. I was able to correctly configure HTTP_PROXY and the plugin correctly loaded data from the API.

Currently, this variable has been set permanently. This in itself is a security concern that I have been trying to resolve. My latest attempt was running a Powershell-Script that asks the user for login information, sets these values into the current environment-variables (not permanently writing them) and then starts VS Code.

In VS Code, these variables seem to be correctly inherited (accessing over pwsh or cmd in integrated terminal). Sadly, the plugin doesn't read the inherited variables, as it fails to load api-index.json. Is it possible that I'm making some stupid mistake, or does the plugin not inherit from VS Code?

I really want to avoid setting the variables permanently.

[iljapostnovs]

First, thanks for your hard work. I have been testing the extension the last few weeks, and it works extremely well. Sadly, my company uses an authenticated proxy and therefore limits these network calls that your plugin is making. I was able to correctly configure HTTP_PROXY and the plugin correctly loaded data from the API.

Currently, this variable has been set permanently. This in itself is a security concern that I have been trying to resolve. My latest attempt was running a Powershell-Script that asks the user for login information, sets these values into the current environment-variables (not permanently writing them) and then starts VS Code.

In VS Code, these variables seem to be correctly inherited (accessing over pwsh or cmd in integrated terminal). Sadly, the plugin doesn't read the inherited variables, as it fails to load api-index.json. Is it possible that I'm making some stupid mistake, or does the plugin not inherit from VS Code?

I really want to avoid setting the variables permanently.

Hi, thanks! :) Well, the extension doesn't "inherit" anything from VSCode. HTTP(S)_PROXY env variable support is handled by Axios. In other words, what Axios supports, the extension should support it as well. So, you are setting env variable something like this and it is not working?

https_proxy=http://username:password@proxy.example.com

In other words, my question is: how I can reproduce the issue.

[cyacedev]

Reproducing the issue should be possible if you have a proxy to authenticate against (which could be difficult). In my case, I run a PowerShell-Script with the following content:

$Env:HTTP_PROXY = "http://Username:EncodedPassword@proxy.example.com:port(if need be)"
Start-Process -WindowStyle Hidden code .

In the now opened VS Code window, one can verify the environment variables by opening an integrated terminal (pwsh) and running $Env:HTTP_PROXY. The UI5 Plugin however will report failure to connect to the api-index.json endpoint. If it does work, maybe try to change configured ui5version and clear cache. This will result in the proxy demanding a re-authentication (407).

As an alternative with a permanent write:

$proxy_string = "http://Username:EncodedPassword@proxy.example.com:port(if need be)"
[Environment]::SetEnvironmentVariable('HTTP_PROXY', $proxy_string, 'User')

Now, opening VS Code in any way will of course result in the plugin working.

I'm guessing from your explanation that axios, when being called from your plugin, is not executed in an env that is created by VS Code. Maybe the plugin could (on top of today's logic) try to load HTTP_PROXY value and directly transfer this to axios .

In any case, thanks for explaining the logic. Currently, my script allows me to easily write and delete from the permanent environment-store. It works, but is just not suitable security-wise.

Addendum: I am by no means knowledgeable in VS Code Extension Development, so I cannot say anything about the suitability of such a feature.

Addendum 2: Maybe by reading environmentVariableCollection from the context ? Not sure how this works over different platforms and shells but seems to be a generalized way of accessing it.

[cyacedev]

Scratch my previous statement. After testing a bit, the Variable just seems to be accessable with process.env.HTTP_PROXY. I found a similar process for reading these values in Dart-Code.

Now the only challenge remains to actually pass these to axios.

[iljapostnovs]

That's strange, because Axios is using precisely this env. variable. Axios even has tests for it:

So I am a bit confused about why it is not working for you if you are setting the env variable...

[cyacedev]

Hey, sorry for not posting this, but today I also was able to debug up to this part. The package that axios uses, proxy-from-env, correctly loads these values and parses them neatly. Interestingly, I can verify that it worked up to the configured Header Proxy-Authorization. However it still doesn't work correctly 🤷.

Now the weird thing: When I set the env variable permanently, proxy-from-env actually does not load the variable from proccess.env. It seemingly should not work, but somehow still does.

I'll have to check it in the following weeks but this issue has gotten me real stumped 😓. Thanks for assisting anyways and have a great weekend!

[iljapostnovs]

ow the weird thing: When I set the env variable permanently,

Thanks and have a nice weekend as well :) I would be glad to help more, but I don't really have any real proxy to test the issue. If you have any ideas what could help you, please let me know. I can create separate config for proxy and send it directly to axios or actually reuse proxy preferences from VSCode ( ) , but after your explanation (I can verify that it worked up to the configured Header Proxy-Authorization. However it still doesn't work correctly 🤷.) I am not sure that it would help :)

[cyacedev]

Correct, that may just make the application more complex with no benefit. I will have to first test in a separate app that just tests our company's proxy config directly in the axios.get() config.

[cyacedev]

Will close the issue for the immediate future, as the cause is highly probable to be company-specific. Will reopen if I gather something that could improve the plugin.