auth0/auth0-deploy-cli

Export from a new tenant includes non-permitted flag require_signed_request_object

yossarian21 opened this issue · 4 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

I set up a new tenant and exported config from it using format: 'yaml'.

The resulting tenant.yaml includes:

tenant:
  flags:
    require_signed_request_object: false

If I immediately try to import this into the same tenant, I get an error:

Bad Request: Updating the require_signed_request_object flag is not allowed. Please contact us if you need additional information.
    at fn (/app/node_modules/rest-facade/src/Client.js:402:25)
    at Request.callback (/app/node_modules/superagent/src/node/index.js:923:3)
    at fn (/app/node_modules/superagent/src/node/index.js:1153:18)
    at IncomingMessage.<anonymous> (/app/node_modules/superagent/src/node/parsers/json.js:19:7)
    at IncomingMessage.emit (node:events:525:35)
    at IncomingMessage.emit (node:domain:489:12)
    at endReadableNT (node:internal/streams/readable:1359:12)
    at processTicksAndRejections (node:internal/process/task_queues:82:21) {
  statusCode: 400,
  requestInfo: {
    method: 'patch',
    url: 'https://<tenant>.us.auth0.com/api/v2/tenants/settings'
  },

I can't find this flag in the tenant settings UI (or I don't understand what it is) but I haven't modified any of the tenant-level settings other than inviting members, setting a Friendly Name, and setting the Logo URL.

Workaround: Remove require_signed_request_object from flags

Expectation

I should be able to re-import the config that was just exported from a new tenant.

Reproduction

  1. Given I have just created a new tenant and set up a Deploy CLI M2M application
  2. When I export the tenant config to YAML
  3. Then I should be able to re-import the same config to the same tenant
  4. Bug: I get a bad request error

Deploy CLI version

7.17.2

Node version

18.16.0

Maybe something to consider: The fact that an export also obfuscate access keys also makes an export impossible to directly import, since it will replace the actual credentials with these markers created by the export. If this bug is addressed, I would suggest the export to omit the credentials property all together, or the import to ignore/warn for this specific value (that is to be considered to be a marker rather than an actual value).

emailProvider:
  credentials:
    accessKeyId: '##SES_ACCESS_KEY_ID##'
    secretAccessKey: '##SES_ACCESS_SECRET_KEY##'

@yossarian21 As you've discovered, some exported tenant flags are not compatible with new tenants. This situation can arise for a myriad of reasons, but most notably can occur if the target tenant was created at a time where certain feature flags were deprecated.

In these cases, it is safe to remove the require_signed_request_object (or any other problematic flag) property entirely. I do admit that this situation is annoying, so we are investigating the possibility of checking flag compatibility before writing to the tenant. This work has even been proposed with #792 but has not been thoroughly vetted yet.

@andreas-lundgren-qlucore what you are describing is a separate from OP's issue. Please open a separate issue for tracking.

A fix for this was introduced with #797 and released with 7.17.4. I included a pretty thorough writeup of the context, problem and proposed solution. But to summarize, the tenant has a flags property which is a map of boolean values that toggle various pieces of functionality for the entire Auth0 product. Some of these flags are intended to be public, others are meant to be hidden and some are somewhere in this in-between area. On occasion, especially when transferring configuration from one tenant to another, incompatibilities may arise. The solution here is to only allow the modification of public tenant flags. This will eliminate nearly all incompatibles arising from tenant flags with no perceived side effects to the end user.