Accessing a File Share on a Storage Account with an app specific proxy results in a timeout issue

[soloji]

Preflight Checklist

• [X] I have installed the latest version of Storage Explorer.
• [X] I have checked existing resources, including the troubleshooting guide and the release notes.
• [X] I have searched for similar issues.

Storage Explorer Version

1.21.0

Regression From

1.10.1

Architecture

i86

Storage Explorer Build Number

20210908.7

Platform

Windows

OS Version

Windows 10 Enterprise 1909

Bug Description

File Share doesn't seem to uses the application specified proxy. We have specified an app specific proxy for Azure Storage Explorer but when attempting to browse to the "File Share" of an account the access times out with the image below. In the old version we would see traffic on the proxy server when opening File Shares such as .file.core.windows.net:443. However in this version we see no traffic attempting to reach the specified proxy.

Steps to Reproduce

1. Launch Storage Explorer
2. Specify application specific proxy - no bypass specified
3. Add account
4. Attempt to navigate to File Share that you have permission to (note that blobs work as expected)
5. Error will appear

Actual Experience

When attempting to open File Shares I get the following error that seems to indicate that traffic is not being direct to the specified proxy

Expected Experience

Able to open the File Share when using a application specific proxy

Additional Context

This is a major jump in version for our organisation 1.10.1 to 1.21.0 and I appreciated this might of broken in much earlier versions.

[soloji]

I was able to get our teams to install 1.20.1 and the issue is not present in that version. I am able to browse to the File Share as expected and I can see the traffic on the proxy.

[craxal]

I'm not able to reproduce when using Fiddler as a proxy on my machine. Can you please share your log files with us for both "main" and "se-file-extension"? You can find the log files by selecting Help > Open Logs Directory from the menu.

Is it possible to use system proxy settings or environment variables? Does this problem reproduce if you try those options?

Another thing you can do:

1. Launch Storage Explorer and open the dev tools by pressing F12.
2. In the Source tab, press Ctrl+P, enter FileManager.js and open the corresponding file.
3. Look around line 33 for code in a function called listFileSharesSegmented and that looks like the following and drop a breakpoint:

   fileService.getShareProperties(fileShareName, function (error, result) {

4. Follow your repro steps until the breakpoint is hit.
5. Hover over the fileService variable and look for the value of the proxy property. Does the object appear to match your proxy settings?

[soloji]

Thanks craxal, Because of corporate environment it is hard to override system proxy settings or environment variables and our users aren't very tech savvy to say the least. Getting them to use the GUI is very useful for me, I have attached the logs and done the breakpoint as requested all seem to point to the external proxy.

Is it possible that your fiddler is working because it is listening locally on 3128 and the error indicates that it is trying to connect to 127.0.0.1:3128 - thus would work with a local fiddler that is listening on 127.0.0.1?

Have you tried with an external proxy - squid should be about 20mins of work to get running on another machine or maybe fiddler listening on another machine?

2021-09-16_114127_se-managed-disks-extension_16916.log 2021-09-16_114127_main.log

[craxal]

@soloji Can you also provide the logs for the "se-file-extension" process? Since the problem you're having is with file shares, that may be more informative. Have you also confirmed that you are using the correct protocol, username, and password?

If your OS is already configured to go through the same proxy, it may be easier for you to change Storage Explorer's settings to "Use system proxy".

I will try setting up a real proxy on my end and see if I can reproduce the issue. To confirm, what kind of authentication does your proxy server use?

[MRayermannMSFT]

it may be easier for you to change Storage Explorer's settings to "Use system proxy".

@craxal this will not work, file share features are not onboarded to system proxy at this time.

[craxal]

@soloji FYI, I've been wrestling with Squid and other proxy options for a while but have not been successful in getting anything to work except Fiddler locally, let alone get Storage Explorer to work with it.

I mentioned it before, but I want to make sure. The log files seem to indicate that you have a username and password, but "Use credentials" is turned off. Assuming your proxy uses Basic authentication, does your proxy expect a username and password?

Are there any other resource types or areas where proxy isn't working (such as Queues or Tables)?

[soloji]

@craxal Good morning, thanks for trying to reproduce! Our proxy is not expecting a user name and password. It uses no authentication

I will get the logs of the file that you requested shortly

[soloji]

Two findings this morning

1. No logs are generated for the se-fileextension-process, it only seems to generate logs for the successful processes (is there debugging I can turn on?)
2. The tables feature also suffers the same issue (we don't use this, so I hadn't checked till you prompted me, thanks!) One difference between the file and tables is that tables fails immediately compared to tables that fails after a while (I expect that is just a retry/wait logic on the files vs tables)

[craxal]

@soloji Thanks for the info. I was able to reproduce the same behavior using a simple Node script to act as a proxy on a different machine. Blobs and Queues work, but Files and Tables do not. The key difference is we use different SDK versions, and so setting up the proxy is different for each version.

Since you say it doesn't reproduce in 1.20.1, can you follow the same steps above involving the dev tools with that version? I'm curious to see if the proxy value is different between versions.

[craxal]

I think I found the problem. In 1.21.0, we changed just a little bit how we pass app proxy settings to the File and Table clients. However, the SDK documentation was misleading, so we ended up passing the settings in the wrong format. Not entirely sure why this error is only apparent when working with a non-local proxy, but I tested the fix, and it seems to be working.

@soloji Would you like to try out a private build to see if the change fixes your issue?

[soloji]

@craxal great news! I always think that once an expert can reproduce, the fix is not far away

would be happy to test, might take a business day or two as I need to get things whitelisted but I should be able to test by early next week.

[craxal]

@soloji You can download the build from here. It's possible we may ship a hotfix early next week, so the sooner you can try out this build and verify it works, the better.

[soloji]

@craxal I have installed the build you provided and the file and table function is working with our proxy. Thank you very much for the fast turn around on this issue