Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keyword replacement logic doesn't preserve items within guardianFactorProviders #845

Closed
6 tasks done
brendenpalmer opened this issue Aug 23, 2023 · 10 comments
Closed
6 tasks done
Labels

Comments

@brendenpalmer
Copy link
Contributor

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

@willvedd
Copy link
Contributor

@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.

@brendenpalmer
Copy link
Contributor Author

@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

@esumerfd
Copy link

esumerfd commented Oct 27, 2023

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##
}

@willvedd
Copy link
Contributor

@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.

@willvedd
Copy link
Contributor

@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
Copy link

mrsarm commented Nov 24, 2023

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.

@willvedd
Copy link
Contributor

@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.

@willvedd
Copy link
Contributor

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.

@LeeJW1987
Copy link

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

@rakeshpawar09
Copy link

7.24.2 and 7.24.1 have the same issue , audience param is not getting preserved during export.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants