Skip to content

Conversation

@MicroFish91
Copy link
Contributor

@MicroFish91 MicroFish91 commented Nov 6, 2025

Overview

This PR adds a secure auth layer that clients should interface with to obtain the Azure Resources core APIs (used for registering branch data resources). For full details on the new auth handshake, please see the auth readme included with this PR. We will continue to publicly provide the core APIs while we let clients onboard. Afterwards we will remove these APIs from the public exports and only expose them through the dedicated auth layer.

Setup

Here are the steps if you would like to try out the changes:

  1. Pull down this branch
  2. npm install & npm run compile in Azure Resources root
  3. npm install & npm pack in Azure Resources API root
  4. Pull down one of the client extension sample branches below
  5. npm install and add the Azure Resources API package built from step 3
  6. Launch Client Extension + Host, observe the onDidReceiveAzureResourcesApis callback to verify we are getting matching Azure Resources APIs

Client Extension Samples

Container Apps example (V2): microsoft/vscode-azurecontainerapps#992
Functions example (internal + V2): microsoft/vscode-azurefunctions#4777

Todos

To add in follow-up PRs.

1. The client extension should then use the Azure Resources credential to retrieve the Azure Resources APIs by calling `getAzureResourcesApis`.

### Diagram
![Azure Resources API Request Handshake](https://github.com/microsoft/vscode-azureresourcegroups/blob/main/api/docs/media/api-request-handshake.png)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: Some of these new links will look broken until the PR gets merged

Copy link
Contributor Author

@MicroFish91 MicroFish91 Nov 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume you won't need to pay much attention to the changes from this file since it's auto-generated based on all the other types in the repo**

@MicroFish91 MicroFish91 marked this pull request as ready for review November 11, 2025 00:22
@MicroFish91 MicroFish91 requested a review from a team as a code owner November 11, 2025 00:22
clientCredential = await clientCredentialManager.createCredential(context.clientExtensionId);
} catch (err) {
if (err instanceof Error) {
await context.onApiRequestError?.({ code: AzureResourcesApiRequestErrors.CLIENT_FAILED_CREATE_CREDENTIAL.code, message: clientCredentialManager.maskCredentials(err.message) })
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For these onX you should void them or consider maybe VSCode's EventEmitter. If the awaited callback throws, then this would also throw.

Copy link
Contributor Author

@MicroFish91 MicroFish91 Nov 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call, I changed to use void. That said, I actually realized while testing that because I'm already voiding here at the top level:

image

Any errors thrown won't actually bubble up to the user because it's already in another process (at least for the first part of the handshake).

I added this note as well so other clients understand the implications of this behavior:
image
I'll probably want to update the README with this as well.

Here's how I might show a user the error instead of throwing it (from updated ACA branch):
image

Let me know if you have any additional thoughts / concerns on doing it this way

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. I think we could get away with just output logging, sans telemetry...once we have it tied up right there's really no reason it should ever go wrong.

/**
* List of errors that could occur during the authentication handshake between client extension and Azure Resources host extension.
*/
export const AzureResourcesApiRequestErrors = {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there should be a type here to enforce the shape on the errors.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed this to an enum instead, and the type is defined as part of AzureResourcesApiRequestError below

@MicroFish91
Copy link
Contributor Author

MicroFish91 commented Nov 19, 2025

Putting back into draft temporarily, I ended up reworking this logic a little bit after finishing up the test writing. Will take out of draft once I've updated with said changes.

@MicroFish91 MicroFish91 marked this pull request as draft November 19, 2025 04:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants