Add listSubscriptions to resourceApi

[nturinski]

Relies on microsoft/vscode-azuretools#1703

I was trying to add a getSubscription function on the provider itself, but for some reason, getAzureSubscriptionProvider kept throwing an error, saying that it wasn't a function. 🤷

I'm okay with my current solution, but was really confused as to why it wasn't working.

[alexweininger]

Which provider did you try to add it to?

[nturinski]

Which provider did you try to add it to?

I added it to src/tree/azure/AzureResourceTreeDataProviderBase.ts

[bwateratmsft]

Why do we need this vs. using the auth package?

[nturinski]

I need a way to list the filtered subscriptions to create my own SubscriptionListStep for a user to select their sub in the Functions and Storage extension. Since I don't think we'd want the client extensions to directly consume the auth package, I was planning on having Resources handle listing the subs out to the clients.

Resources also controls the tenant/subscription filter settings, so I thought it made more sense for it to deliver the list to the clients.

[bwateratmsft]

I'd still lean toward using the auth package since it internally handles the subscription filters. Also, at a minimum we should designate this API as meant for internal use; I don't want Azure Resources becoming a de facto Azure Account extension.

Perhaps we could implement it on the on the extension's API but not declare it in utils.

[nturinski]

I'd still lean toward using the auth package since it internally handles the subscription filters.

So I was exploring this-- it seems like I could create a VSCodeAzureSubscriptionProvider within Functions. The issue seems that each extension requires permissions to use the Microsoft Authenticator, so unless I'm getting the session from Resources, the user will have to sign in again.

Do you know if there's a way around this? I think for usability, having the user sign in again is a no-go. I'm cool with not exposing it in the API.

[bwateratmsft]

There is not a way around that, it's very intentional on the part of VSCode's auth model that each extension has to explicitly get permission to use an account. That degraded UX makes sense though, I think it's OK to expose this listSubscriptions method in the Azure Resources extension, I just wouldn't put it on the API or docs. Or do, but mark it deprecated with an "for internal use only" message or something like that.

[nturinski]

Do you mean like this?
microsoft/vscode-azuretools#1704

[bwateratmsft]

Do you mean like this? microsoft/vscode-azuretools#1704

Spot on!