auth0/auth0-deploy-cli

Keyword replacement logic doesn't preserve items within `guardianFactorProviders`

brendenpalmer opened this issue ยท 10 comments

Checklist

  • I have looked into the README and have not found a suitable solution or answer.
  • I have looked into the documentation and have not found a suitable solution or answer.
  • I have searched the issues and have not found a suitable solution or answer.
  • I have upgraded to the latest version of this tool and the issue still persists.
  • I have searched the Auth0 Community forums and have not found a suitable solution or answer.
  • I agree to the terms within the Auth0 Code of Conduct.

Description

Keywords within guardianFactorProviders don't seem to be preserved as expected on export. The default config for guardianFactorProviders is here: src/tools/auth0/handlers/guardianFactorProviders.ts#L34. It sets id to name, which conflicts with logic here: src/keywordPreservation.ts#L235 and its usage here: src/keywordPreservation.ts#L56; as a result, it'll attempt to match based on id, but id won't exist in the tenant.yml file so the keyword will ultimately never be preserved.

Expectation

Should have keywords preserved within guardianFactorProviders

Reproduction

See failing test-case here: https://github.com/auth0/auth0-deploy-cli/compare/master...brendenpalmer:auth0-deploy-cli:failing-test-case-guardian-factor-providers?expand=1

Deploy CLI version

7.19.0

Node version

19.7.0

@brendenpalmer Thanks for opening this ticket, especially appreciative of the unit test. This is definitely a bug that impacts all of the guardian resource types. Will need to dig into this a bit further but think we can address it sometime in the near future.

@willvedd I wonder if an option could be to not filter out the handler id when constructing resourceSpecificIdentifiers and instead match on all identifiers, but skip keys not present on the resource when constructing the specific address. Potentially something like: 8a8696e

This may be related. I am attempting to disable guardian factors sms.json. If true updates but when false it does nothing.

json/guardian/factors/sms.json
{
  "name": "sms",
  "enabled": ##ENABLE_SMS##
}

@brendenpalmer Thanks for raising that commit. At first glance it appears that it should work but I'll need to apply more tests to confirm. If good, I'd like you to submit a PR so that you can claim credit for this open source contribution.

@esumerfd I believe you're referring to a separate issue. I'd leverage the @@ literal-replacement syntax instead of the ## string-replacement syntax. This should achieve your desired result. Although, on subsequent export, that replacement marker will get blown away due to OP's issue.

Example:

{
  "name": "sms",
  "enabled": "@@ENABLE_SMS@@"
}
mrsarm commented

I was having the same issue in a project also with the version 7.19.0, and downgrading to 7.18.0 solved the problem for me, although there are other tickets reported in this project by people having the same issue with the older version too.

The audience placeholder was replaced by the actual value during the export with the newest version:

tenant.yaml:

clientGrants:
  - ...
  - client_id: Portal App
    audience: '##API_AUDIENCE##'
    scope:
      - read:users
      - update:users
      - ...

config.stage.json:

{
  ...
  "AUTH0_ALLOW_DELETE": true,
  "AUTH0_PRESERVE_KEYWORDS": true,
  "AUTH0_KEYWORD_REPLACE_MAPPINGS": {
    "API_AUDIENCE": "https://some-stage-domain.auth0.com/api/v2/",
    "ALLOWED_LOGOUT_URLS": [
      ...
    ],
    "CALLBACKS": [
      ...
    ]
  }
}

Command executed: a0deploy export --format=yaml -c config.stage.json --output_folder=resources.

@mrsarm You're describing a similar but separate issue that's discussed in #855. Please see my comment about it. AFAIK, simply downgrading will not fix the issue.

This specific keyword preservation issue has been fixed with 7.20.0. It should improve the feature's coverage to not just guardianFactorProviders but for many more resources. Appreciate everyone's feedback here.

I was having the same issue in a project also with the version 7.19.0, and downgrading to 7.18.0 solved the problem for me, although there are other tickets reported in this project by people having the same issue with the older version too.

The audience placeholder was replaced by the actual value during the export with the newest version:

tenant.yaml:

clientGrants:
  - ...
  - client_id: Portal App
    audience: '##API_AUDIENCE##'
    scope:
      - read:users
      - update:users
      - ...

config.stage.json:

{
  ...
  "AUTH0_ALLOW_DELETE": true,
  "AUTH0_PRESERVE_KEYWORDS": true,
  "AUTH0_KEYWORD_REPLACE_MAPPINGS": {
    "API_AUDIENCE": "https://some-stage-domain.auth0.com/api/v2/",
    "ALLOWED_LOGOUT_URLS": [
      ...
    ],
    "CALLBACKS": [
      ...
    ]
  }
}

Command executed: a0deploy export --format=yaml -c config.stage.json --output_folder=resources.

@mrsarm this worked for me too
@willvedd FYI