Better support for Multi-Root VS Code Workspaces

[aersam]

Which service(blob, file, queue, table) does this issue concern?

All of them

Which version of the Azurite was used?

Latest VS Code Extension v3.23.0

Steps to reproduce the issue?

I created a Multiroot workspace with VS Code. Whenever I start Azurite I get asked for the location it should run, even if I configure it in the .code-workspace file. As I'm lazy, I'd prefer picking up the setting

[blueww]

@aersam

Currently, when you do not configure the location of Azurite VS extension, by default Azurite VS extension will use the current opened folder as the location. However, as you use Multiroot workspace, there are multiple folders are opened, so Azurite don't know which folder to choose as location.

You can configure an absolute path in Azurite Extension Settings -> Azurite:Location, like following:

[danielniccoli]

I'm working on a Azure Functions project that calls an Azure Durable Functions project. I created a multi-root workspace. My issue is that each Azure Functions project should use its own storages. Either by spawning two Azurite instances or by changing the account name on the Azure Functions.

Spawning two Azurite instances is impossible in a multi-root and telling the Azure Functions to use different accounts is also tricky (I have not gotten it working).

So I support this ticket. At the moment it is too difficult to work with Azurite in a multi-root workspace - if not to say impossible.

[blueww]

@danielniccoli

Do you mean you run Azure Functions projects in same time, and you expect each Azure Functions project has its own storages account (different project won't impact each other on storage data)?

Normally, you should make each Azure Functions project use different storage account. (even you use product Azure, this is also the correct way.) So you might should look into how to make different Azure Functions projects to use different accounts. (You can also start Azurite with multiple accounts with https://github.com/Azure/Azurite#customized-storage-accounts--keys)

If you really would like to start multiple Azurite instances on the same time on same machine, you need to make different Azurite instance start on different port with https://github.com/Azure/Azurite#customize-blobqueue-service-listening-port (or there will be port conflict). However, in this way, you need to make Azure Functions projects to connect to azurite with different port.

Please understand we are not Azure function expert. So in this case, you might can access Azure Function team for help.

[danielniccoli]

My point is that configuring and running Azurite in a multi-root workspace in VS Code is too difficult, or even impossible.

For example, how do I pass the setting from the AZURITE_ACCOUNTS environment variable to Azurite, if I am using VS Code to start Azurite? The option with the environment variable works only for the npm cli, as mentioned in the docs:

Then there is issue #2086 which -- has nothing to with multi-root workspace support, but -- makes it more difficult to configure Azurite. In a multi-root workspace I would add a folder to the workspace specifically for the azurite data and then set the azurite.location setting to ${workspaceFolder:.azurite}.

As far as I can see, we're also missing the option to change the default container name (not the account) from devstoreaccount1 to something else.

[aersam]

I completely agree with @danielniccoli . Using Azurite in a multi-root workspace is really hard, I personally gave up and run it using another VS Code window :) Maybe I'm just using it the wrong way and some docs would help.

[danielniccoli]

@aersam Did you manage to set the location? I did get it working how @blueww described earlier in the post. I still struggle with the accounts, though -- as you may saw from my other comments. If you still need help, I might be able to assist.

[blueww]

@danielniccoli

For pass the setting from the AZURITE_ACCOUNTS environment variable to Azurite VS code extension, I have tested following way works, would you please try:

1. set the environment variable in "Advanced system settings", see more detail in https://www.computerhope.com/issues/ch000549.htm
2. start a new VS code console , and start Azurite

For "missing the option to change the default container name (not the account) from devstoreaccount1 to something else", Would you please clarify what's the detail function of the option? The storage account in Azurite will be an empty account and not has any default container.

[danielniccoli]

Appreciate your comment, @blueww , but this is not a good solution. There should be a setting for it. And Azurite should also look into local.settings.json if it exists.

If I set the connection string to containers different than .../devstoreavcount1, I get 404 resource not available for all calls.

[blueww]

@danielniccoli

For some security consideration, currently we only support set the account name/key in environment variable.

For the 404, I don't get how you repro it. (If your error is "The specified resource does not exist.", you might use wrong account name in the request Uri.) You might can give the detail step to repro it, which should include: Azurite version, the way to start Azurite, Azurite debug log.

[danielniccoli]

@blueww , I'll create a reproducible case, but it will take a little.

As for the security consideration, could you describe your concerns, or the possible attack vectors? Azurite is an emulator for dev purposes, no? Local.settings.json is explicitly to store bogus credentials on local machines, to separate dev and production and not risk leaking production credentials into CVS. I cannot image any security risk, but I'm eager to learn.

[blueww]

For security consideration, if we allow user to input the customized account name/key in command parameter, there might be some logging system that will log every command include parameters, so currently put it to Environment variable. The default account name/key of Azurite is public, but for the customized account name/key, this could be none-public and some customer might don't want it be leaked.

[danielniccoli]

What do you mean by "command parameter"? Do you mean the command palette?

I'm talking about the local.settings.json file, which is a place specifically meant and absolutely intended to put secrets for your local development environment.

You're saying there are security considerations behind your decision to not use that file for passing account and secret to the Azurite emulator, but the entire world of ASP.NET Core and Azure Functions developer (to pick just two) agreed upon this practice. It does not make sense that a small team chooses to go against the grain, and in turn make everything more difficult for everybody working with it.

there might be some logging system that will log every command include parameters, so currently put it to Environment variable

Putting it in the system environment variable -- like you suggested -- is worse, because now every user and every process can just read $env:AZURITE_ACCOUNT. Your previous statement directly conflicts with your workaround.

Does not compute.

I beg you to reconsider.

[blueww]

@danielniccoli I am still discussing this with my colleagues. Will update you when we get some conclusion.

[blueww]

@danielniccoli

For the sample you provide, it looks Azure Functions allows to adding credential in a "local.settings.json" file of the extension instead of the shared settings.json of VS Code. Currently Azurite still doesn't have its own settings file. And we are working on some new storage feature implementation, so this won't be our priority recently.

Azurite welcome contribution! It would be great if you could raise a PR to add the setting file with the Azurite Account setting! (Please review the design with us to get agreement , so we can have a smooth PR review. The design should include but not limited to: the setting file name/path/permission, the settings supported in the file and each setting format, how to handle conflict with environment variable, ...)