auth0-training / labs-vscode-extension Goto Github PK

Existing Auth0 Codetours allow learners to click an embedded link to visit the URL of their launched app. The URL for this link is retrieved via the Auth0 Labs VSCode extension command auth0.lab.openEndpointByName?[<Lab Name>]. In GitHub Codespaces, this currently grabs the incorrect URL (See: https://imgur.com/a/OrCyuN4). We need to check for the Codespaces context and grab the correct link using the appropriate GitHub Codespaces env variables:

https://${process.env.CODESPACE_NAME}-${PORT}.${process.env.GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN}

Describe the problem you'd like to have solved

When the user runs localConfiguration through the extension, the user should see some sort of visual indication in the UI that configuration was successful or not. It may be worth notifying the user when there is an app specified in the yml file that could not be found in the connected tenant (not an "error", but helpful in troubleshooting when a user accidentally grants access to the wrong tenant).

Describe the ideal solution

The user runs localConfiguration. Upon success, a confirmation toast pops up informing them that the configuration process was a success, and which apps/APIs have been configured. Otherwise, display a warning that .env was not created since app config was not found in the tenant.

Idea

Could potentially display a troubleshooting guide hosted on a default tenant.

Describe the problem you'd like to have solved

Description

Github recently changed the Codespaces port forwarding domain, which broke configs of the Allowed login and Callback URLs. To avoid this in the future, we should get the value from the Github Codespaces env variable GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN instead of hardcoding the value. This env variable needs to be made available for keyword replacement.

Given the following resources.yml configuration:

clients:
  - name: ExampleWebApp
    app_type: regular_web
    allowed_logout_urls:
      - http://localhost:3000
      - https://##CODESPACE_NAME##-37500.##GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN##
    callbacks:
      - http://localhost:3000/callback
      - https://##CODESPACE_NAME##-37500.##GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN##/callback
clientGrants:
  - client_id: ExampleWebApp
    audience: https://##AUTH0_DOMAIN##/api/v2/
    scope:
      - read:users

When a user attempts to configure a lab, the deployment will fail because:

• GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN is not available as a keyword replacement and will cause an invalid entry to be written to the tenant application registration

This value are available at runtime to the extension and can be passed as default values so these substitutions work correctly.

Describe the ideal solution

These values should be provided as default replacement values during tenant configuration deployment.

Issue is similar to previously solved issue #42

https://github.com/auth0/auth0-deploy-cli/releases/tag/v7.20.0

There's been breaking change that has resulted in Activation Denied when attempting to grant the extension permissions on an Auth0 tenant.

This seems to be related to the fact that the root tenant authority no longer prompts the user to select their tenant, which was behavior we previously were able to achieve by wildcarding the audience (https://*.auth0.com/api/v2/), aka the target API we want the extension to be granted access to.

Extension fails to pull CLIENT_SECRET into .env

Describe the problem you'd like to have solved

Description

Given the following tenant.yml configuration:

clients:
  - name: ExampleWebApp
    app_type: regular_web
    allowed_logout_urls:
      - http://localhost:3000
      - https://##CODESPACE_NAME##-37500.preview.app.github.dev
    callbacks:
      - http://localhost:3000/callback
      - https://##CODESPACE_NAME##-37500.preview.app.github.dev/callback
clientGrants:
  - client_id: ExampleWebApp
    audience: https://##AUTH0_DOMAIN##/api/v2/
    scope:
      - read:users

When a user attempts to configure a lab, the deployment will fail for these reasons:

1. CODESPACE_NAME is not available as a keyword replacement and will cause an invalid entry to be written to the tenant application registration
2. AUTH0_DOMAIN is not available as a keyword replacement and will cause an error to be generated attempting to write the client grants to the management api registration for the tenant.

These values are available at runtime to the extension and can be passed as default values so these substitutions work correctly.

Describe the ideal solution

These values should be provided as default replacement values during tenant configuration deployment.

Describe the problem you'd like to have solved

Given I have an extensibility script that uses a client registration's client id and secret
When I configure a sample application using the VSCode Extension
Then I would like a way to execute a script to store the secret values on completion of configuration

Describe the ideal solution

Currently, resources are defined in the environment.json file like so:

{
  "name": "Impersonation: Custom DB",
  "version": "1.0.0",
  "resources": "../../src/tenant/tenant.yaml",
  "clients": [
    {
      "name": "ExampleWebApp",
      "directory": "src/web-app",
      "env": {
        "ISSUER_BASE_URL": "$tenant_base_url",
        "CLIENT_ID": "$client_id",
        "CLIENT_SECRET": "$client_secret",
        "SECRET": "a long, randomly-generated string stored in env",
        "PORT": 37500
      }
    }
  ]
}

It could be updated like so:

{
  "name": "Impersonation: Custom DB",
  "version": "1.0.0",
  "resources": "../../src/tenant/tenant.yaml",
  "postConfigureCommand": "../../src/tenant/apply-secrets.sh",
  "clients": [
    {
      "name": "ExampleWebApp",
      "directory": "src/web-app",
      "env": {
        "ISSUER_BASE_URL": "$tenant_base_url",
        "CLIENT_ID": "$client_id",
        "CLIENT_SECRET": "$client_secret",
        "SECRET": "a long, randomly-generated string stored in env",
        "PORT": 37500
      }
    }
  ]
}

This command should be executed as a third step in the configureLab method and be available as a stand alone command.

The script should be run with access to environment variables for AUTH0_DOMAIN and AUTH0_TOKEN defined giving the script the ability to interact with the management API. The script is free to fetch values using the local .env files as well.

Version v7.17.2 of the deploy cli has been released and should be updated to support new features and management api checks.

@jesposito identified an issue where having the CodeTour extension installed locally in VSCode can cause the container initialization process to throw an error.

Repo Steps:

1. Install VSCode and the Remote Development and CodTour extensions.
2. Start Docker.
3. Ensure you do not have any containers or images related to the labs in docker.
4. Open one of the labs in VSCode.
5. When prompted to reopen in a container, select yes.

Result:
During the container initialization process, an error is thrown in the remote extension host log that CodeTour cannot be loaded. The unauthenticated codetour is not launched, but the codetour does eventually load and can be started via the CodeTour panel.

Expected:
Having codetour installed should have no effect on containerized labs.

Remediation:
For now, remove codetour from the locally installed VSCode.

Describe the problem you'd like to have solved

Given the following environment.json clients configuration

{
  "name": "Sample",
  "version": "1.0.0",
  "resources": "../../src/tenant/tenant.yaml",
  "clients": [
    {
      "name": "ExampleWebApp",
      "directory": "src/web-app",
      "env": {
        "AUDIENCE": "http://api.com/api",
        "API_URL": "ImpersonationAPI",
        "BASE_URL": "ExampleWebAppUsingImpersonation",
        "ISSUER_BASE_URL": "$tenant_base_url",
        "CLIENT_ID": "$client_id",
        "CLIENT_SECRET": "$client_secret",
        "SECRET": "a long, randomly-generated string stored in env",
        "PORT": 37500
      }
    },
    {
      "name": "ExampleWebAppMiddleware",
      "directory": "src/web-app",
      "env": {
        "IMP_CLIENT_ID":"$client_id",
        "IMP_CLIENT_SECRET":"$client_secret",
        "IMP_AUDIENCE":"https://example.com/impersonate"
      }

Note: Both client registrations write .env values to the same directory.

When the auth0.lab.localConfigure command is executed the extension will write the .env values for the ExampleWebApp and then overwrite those .env values with the ExampleWebAppMiddleware.

Describe the ideal solution

In this case the application found in src/web-app uses one client registration to perform standard authentication, but uses middleware that requires a separate client registration for a specific purpose and has limited scopes.

When two or more registrations exist for the same .env file, the extension should append to the file instead of overwriting it.

Alternatives and current work-arounds

There are not current workarounds for this situation.

Additional context

The current implementation is found in writer.ts.

writeAll = async (resolvers: Resolver[]) => {
    resolvers.forEach(async (resolver) => {
      const uri = vscode.Uri.joinPath(this.worspace, resolver.getDirectory(),  '.env');

      const env = 
        resolver
          .resolveEnv(resolvers)
          .map((i) => `${i.name}=${i.value}`)
          .join('\n');

      await fs.writeFile(uri, Buffer.from(env, 'utf8'));
    });
  };

This method could be updated to read any existing values from the .env file, concat them with the new values, filter for duplicates and then write a new file.