auth0 / auth0-deploy-cli

The Auth0 Deploy CLI is a tool that helps you manage your Auth0 tenant configuration. It integrates into your development workflows as a standalone CLI or as a node module.

---

Help Us Improve Auth0 Deploy CLI – Take Our Survey!

👋 Hello developers! We're on a mission to make Auth0 Deploy CLI the best it can be, and we need YOUR help. We've put together a brief survey to understand how you use Deploy CLI, what you love about it, and where you think we can do better.

Why Should You Take the Survey?

• Direct Impact: Your feedback will directly influence the future of Deploy CLI. Ever wished for a feature or fix? Here's your chance to let us know.
• It's Quick: The survey takes less than 10 minutes to complete.

Privacy

We care about your privacy. All data collected is anonymous and will only be used for improving Auth0 Deploy CLI.

Ready to Make a Difference?

Click here to take the survey

Thank you for helping us make Auth0 Deploy CLI better for everyone!

---

The Auth0 Deploy CLI is a tool that helps you manage your Auth0 tenant configuration. It integrates into your development workflows as a standalone CLI or as a node module.

Supported resource types: actions, branding, client grants, clients (applications), connections, custom domains, email templates, emails, grants, guardian, hook secrets, log streams, migrations, organizations, pages, prompts, resource servers (APIs), roles, tenant settings, themes.

🎢 Highlights • 📚 Documentation • 🚀 Getting Started • 💬 Feedback

---

Highlights

• Multi-Environment Oriented: Designed to help you test your applications' Auth0 integrations from feature branch all the way to production.
• Keyword Replacement: Shared resource configurations across all environments with dynamic keyword replacement.
• Versatile: Integrate into your CI/CD workflows either as a CLI or as a Node module.

Documentation

• Using as a CLI
• Using as a Node Module
• Authenticating with Tenant
• Configuring the Deploy CLI
• Keyword Replacement
• Incorporating Into Multi-environment Workflows
• Excluding Resources From Management
• Resource-specific Documentation
• Available Resource Formats
• Terraform Provider
• How to Contribute

Getting Started

This guide will help you to a working implementation of the Deploy CLI tool used as a standalone CLI. There are three main steps before the Deploy CLI can be run:

1. Create a Dedicated Auth0 Application
2. Configure the Deploy CLI
3. Calling the Deploy CLI

Warning This tool can be destructive to your Auth0 tenant. It is recommended to be familiar with the AUTH0_ALLOW_DELETE configuration and to test on development tenants prior to using in production.

Prerequisites

• Node version 10 or greater
• Auth0 Tenant

Install the Deploy CLI

To run as a standalone command-line tool:

npm install -g auth0-deploy-cli

Create a dedicated Auth0 Application

In order for the Deploy CLI to call the Management API, a dedicated Auth0 application must be created to make calls on behalf of the tool.

1. From the Auth0 dashboard, navigate to Applications > Applications
2. Click “Create Application”
3. On Create application page: a. Name it “Deploy CLI” or similar b. Select “Machine to Machine Applications” as application type c. Click “Create”
4. On the “Authorize Machine to Machine Application” page a. Select “Auth0 Management API” b. Select the appropriate permissions for the resources you wish to manage. Refer to the Client Scopes section for more information. c. Click “Authorize”

Warning The Deploy CLI's own client is unconfigurable by itself to prevent potentially destructive changes.

Client Scopes

The designated application needs to be granted scopes in order to allow the Deploy CLI to execute Management operations.

The principle of least privilege is abided, so it will operate within the set of permissions granted. At a minimum, read:clients need to be selected, but is is recommended to select read:, create: and update: permissions for all resource types within management purview. To enable deletions, the delete: scopes are also necessary.

Configure the Deploy CLI

The Deploy CLI can be configured two ways, through a config.json file and through environment variables. The decision to choose one or both would depend on your specific use case and preferences. More comprehensive information about configuring the tool can be found on the Configuring the Deploy CLI page. However, for this example, the simplest way to get going is by setting the following environment variables:

• AUTH0_DOMAIN
• AUTH0_CLIENT_ID
• AUTH0_CLIENT_SECRET

These values can be found in the “Settings” and “Credentials“ tabs within the Auth0 application created in the previous step.

Calling the Deploy CLI

Finally, with above complete, the Deploy CLI export command can be run:

a0deploy export --format=yaml --output_folder=local

Once the process completes, observe the resource configuration files generated in the local directory. Then, run the import command, which pushes configuration from the local machine to your Auth0 tenant:

a0deploy import --config_file=config.json --input_file local/tenant.yaml

Refer to Using as a CLI documentation for a comprehensive list of flags and options.

Feedback

Contributing

We appreciate feedback and contribution to this repo! Before you get started, please see the following:

• Contribution Guide
• Auth0's General Contribution Guidelines
• Auth0's Code of Conduct Guidelines

Raise an issue

To provide feedback or report a bug, please raise an issue on our issue tracker.

Vulnerability Reporting

Please do not report security vulnerabilities on the public Github issue tracker. The Responsible Disclosure Program details the procedure for disclosing security issues.

---

Auth0 is an easy to implement, adaptable authentication and authorization platform.
To learn more checkout Why Auth0?

This project is licensed under the MIT license. See the LICENSE file for more info.

auth0-deploy-cli's Issues

Import failing with custom database on version 2.2.2

The import of configuration using the cli in our CI process has failed with version 2.2.2 with error

2019-01-13T19:44:52.423Z - �[31merror�[39m: Problem running command import
2019-01-13T19:44:52.423Z - �[31merror�[39m: Schema validation failed loading [
    {
        "keyword": "required",
        "dataPath": ".databases[0]",
        "schemaPath": "#/properties/databases/items/required",
        "params": {
            "missingProperty": ".import_mode"
        },
        "message": "should have required property '.import_mode'"
    }
]
Cmd.exe exited with code '1'.

There looks to be tests failing after the latest commit on this repository with the same error.

Create/delete connection

Hi,

I want my CI to be able to create (and remove) connections on demand. I see that there is an endpoint in the management API: https://auth0.com/docs/api/management/v2#!/Connections/post_connections

Is there a reason why this CLI does not support connection creation and deletion ?

If would be nice if names were at the top, when exporting.

When I create an export of an existing environment, in yaml, in some cases the 'name' attribute is a few attributes down. I am certain this is purely based on how the data is returned. However it would be a lot easier to navigate the resulting file if name, template, identifier and then id (in that order) were the first few elements (if they exist).

Test mode (aka "dry run")

We may want to consider a feature where you can run import but in test mode, so no changes. This would be useful for when deploying to production.

It should be fairly easy to add --test param.

Add support for Configuration Settings deployment

Would like the ability to use deployable secrets into the configuration item instead of the @@variable@@ mapping pattern.

From address cannot be set without an enabled email provider.

Error if deploying email templates as provider not set first.

{"statusCode":400,"error":"Bad Request","message":"From address cannot be set without an enabled email provider."}

Add support for elevating specified connections to be domain level connections

This is currently one of the remaining manual configuration steps we have for our database connection.

This perhaps is a general request for more configurability of connections.

Can't create clients

I am trying to deploy config dumped from one tenant to a new one.
It has successfully created the rules, but when it gets to "Creating clients..." it fails with "Error: This operation must be authorized by Auth0"

I have tried creating the deploy cli client via the Auth0 Deploy CLI Extension as well as manually to ensure that all the client related grants are there but the result is the same in both cases.

Update to auth0-source-control-extension-tools 3.0.0

Hi,
Can this repo be updated to support https://github.com/auth0-extensions/auth0-source-control-extension-tools 3.0.0 ? There are some nice features that would resolve some of the open issues.

Sandbox_version is exported but cannot be imported

Hello, we have some auth0 tenants using the appliance deployment model. When we use the tool to export we get a line like sandbox_version: '4' but when we try to import the same yaml file we get an error like The sandbox_version provided is invalid. Please use one of the available options: []. Is there a way around this without having to manually edit the yaml file, please?

Thanks

Add support for configuring Rules configuration params

Ref auth0-extensions/auth0-source-control-extension-tools@ae7ab39

Seems that the only thing that needs to be done for this to work is to update the "context" initialization (reading ruleConfigs files).

Help with log describing deletion of 1 client

When I run a0deploy with debug output, against the configuration created by a0dump, it says "If implemented would be Deleting 1 clients".

My concern is that at some point in the future this gets implemented and then something is deleted, so I was trying to figure out what it was!

I don't have a json file for my "Deploy" client (a0dump didn't create one) ... is that what this is referring to?

Or ... looking in the local state, I noticed this reference:

"adds": {},
"deletes": [
  "All Applications"
],
"updates": {...}

...is this a bug where "All Applications" is somehow being queued as a (not-yet-supported) deletion?

Entity collections with zero children result in no action on import

Let's say you have a tenant.yaml that contains entity collections with zero children. For example:

clients: []
rules: []
connections: []

If the AUTH0_ALLOW_DELETE environment variable was set to true and you peformed an Import, the expected behavior would be that the Deploy CLI would remove all existing entities from the tenant (eg. the YAML above would remove all existing Rules and Clients). However, the actual behavior is that those entities are ignored (skipped). This makes it impossible to craft a YAML file that wipes all entities from a tenant, which is useful in certain circumstances.

Ignoring an entity is also useful. I suggest for that we do so if a particular entity collection is simply not present in the YAML. For example, if you wanted your YAML to ignore rules, then the above YAML file change to this:

clients: []
connections: []

NOTE

Making the above suggested behavioral change to the CLI could be destructive to users who cuurently have YAML files that don't follow this paradigm. We may want to introduce a new environment variable to trigger it (eg. AUTH0_ALLOW_DELETE_ALL_ENTITIES_IN_EMPTY_COLLECTION).

I haven't tested it, but this may also be an issue with the directory format as well.

CLI does not work well with node version 5.11.*

2017-08-22T20:27:33.343Z - error: uncaughtException: Block-scoped declarations (let, const, function, class) not yet supported outside strict mode date=Tue Aug 22 2017 20:27:33 GMT+0000 (UTC), pid=224, uid=0, gid=0, cwd=/opt/atlassian/pipelines/agent/build, execPath=/usr/local/bin/node, version=v5.11.0, argv=[/usr/local/bin/node, /usr/local/bin/a0deploy, -i, ., -c, ./scripts/..//config.json], rss=59060224, heapTotal=41672992, heapUsed=29427408, loadavg=[11.93994140625, 9.75732421875, 8.58837890625], uptime=30824, trace=[
column=16, file=vm.js, function=exports.runInThisContext, line=53, method=runInThisContext, native=false,
column=25, file=module.js, function=Module._compile, line=387, method=_compile, native=false,
column=10, file=module.js, function=Module._extensions..js, line=422, method=.js, native=false,
column=32, file=module.js, function=Module.load, line=357, method=load, native=false,
column=12, file=module.js, function=Module._load, line=314, method=_load, native=false,
column=17, file=module.js, function=Module.require, line=367, method=require, native=false,
column=19, file=internal/module.js, function=require, line=20, method=null, native=false,
column=15, file=/usr/local/lib/node_modules/auth0-deploy-cli/node_modules/auth0-source-control-extension-tools/src/auth0/rules.js, function=null, line=5, method=null, native=false,
column=34, file=module.js, function=Module._compile, line=413, method=_compile, native=false,
column=10, file=module.js, function=Module._extensions..js, line=422, method=.js, native=false,
column=32, file=module.js, function=Module.load, line=357, method=load, native=false,
column=12, file=module.js, function=Module._load, line=314, method=_load, native=false,
column=17, file=module.js, function=Module.require, line=367, method=require, native=false,
column=19, file=internal/module.js, function=require, line=20, method=null, native=false,
column=77, file=/usr/local/lib/node_modules/auth0-deploy-cli/node_modules/auth0-source-control-extension-tools/src/auth0/index.js, function=null, line=1, method=null, native=false,
column=34, file=module.js, function=Module._compile, line=413, method=_compile, native=false,
column=10, file=module.js, function=Module._extensions..js, line=422, method=.js, native=false,
column=32, file=module.js, function=Module.load, line=357, method=load, native=false,
column=12, file=module.js, function=Module._load, line=314, method=_load, native=false,
column=17, file=module.js, function=Module.require, line=367, method=require, native=false,
column=19, file=internal/module.js, function=require, line=20, method=null, native=false,
column=15, file=/usr/local/lib/node_modules/auth0-deploy-cli/node_modules/auth0-source-control-extension-tools/src/deploy.js, function=null, line=2, method=null, native=false,
column=34, file=module.js, function=Module._compile, line=413, method=_compile, native=false,
column=10, file=module.js, function=Module._extensions..js, line=422, method=.js, native=false,
column=32, file=module.js, function=Module.load, line=357, method=load, native=false,
column=12, file=module.js, function=Module._load, line=314, method=_load, native=false,
column=17, file=module.js, function=Module.require, line=367, method=require, native=false,
column=19, file=internal/module.js, function=require, line=20, method=null, native=false], stack=[SyntaxError: Block-scoped declarations (let, const, function, class) not yet supported outside strict mode, at exports.runInThisContext (vm.js:53:16), at Module._compile (module.js:387:25), at Object.Module._extensions..js (module.js:422:10), at Module.load (module.js:357:32), at Function.Module._load (module.js:314:12), at Module.require (module.js:367:17), at require (internal/module.js:20:19), at Object. (/usr/local/lib/node_modules/auth0-deploy-cli/node_modules/auth0-source-control-extension-tools/src/auth0/rules.js:5:15), at Module._compile (module.js:413:34), at Object.Module._extensions..js (module.js:422:10), at Module.load (module.js:357:32), at Function.Module._load (module.js:314:12), at Module.require (module.js:367:17), at require (internal/module.js:20:19), at Object. (/usr/local/lib/node_modules/auth0-deploy-cli/node_modules/auth0-source-control-extension-tools/src/auth0/index.js:1:77), at Module._compile (module.js:413:34), at Object.Module._extensions..js (module.js:422:10), at Module.load (module.js:357:32), at Function.Module._load (module.js:314:12), at Module.require (module.js:367:17), at require (internal/module.js:20:19), at Object. (/usr/local/lib/node_modules/auth0-deploy-cli/node_modules/auth0-source-control-extension-tools/src/deploy.js:2:15), at Module._compile (module.js:413:34), at Object.Module._extensions..js (module.js:422:10), at Module.load (module.js:357:32), at Function.Module._load (module.js:314:12), at Module.require (module.js:367:17), at require (internal/module.js:20:19)]
npm info lifecycle [email protected]~postdeploy: [email protected]

Exporting a tenant multiple time should result in the same tenant.yml

Currently, running a0deploy export -f yaml multiple times does not result in the same tenant.yml. In specific, the multiple emailTemplates in tenant.yml are not in the same order after each export.

This makes it really difficult to compare changes programmatically after exporting settings. Maybe these need to be sorted by value (i.e. emailTemplates.template's value) so that there aren't blocks of config moving around unnecessarily.

I would assume this could apply to other multi-value properties too.

Handle 429 Too Many Requests errors

I would expect an auth0 client to understand a 429 response issued by the auth0 servers and back off gracefully.

2018-08-02T05:13:22.210Z - debug: Error: {"statusCode":429,"error":"Too Many Requests"}
2018-08-02T05:13:22.210Z - debug: StackTrace: APIError: {"statusCode":429,"error":"Too Many Requests"}
    at /tmp/node_modules/rest-facade/src/Client.js:295:21
    at Request.callback (/tmp/node_modules/superagent/lib/node/index.js:688:3)
    at /tmp/node_modules/superagent/lib/node/index.js:883:18
    at Stream.<anonymous> (/tmp/node_modules/superagent/lib/node/parsers/json.js:16:7)
    at emitNone (events.js:106:13)
    at Stream.emit (events.js:208:7)
    at Unzip.<anonymous> (/tmp/node_modules/superagent/lib/node/unzip.js:53:12)
    at emitNone (events.js:111:20)
    at Unzip.emit (events.js:208:7)
    at endReadableNT (_stream_readable.js:1056:12)
    at _combinedTickCallback (internal/process/next_tick.js:138:11)
    at process._tickCallback (internal/process/next_tick.js:180:9)
2018-08-02T05:13:22.214Z - error: Exiting due to error: {"statusCode":429,"error":"Too Many Requests"}
2018-08-02T05:13:22.214Z - error: APIError: {"statusCode":429,"error":"Too Many Requests"}
    at /tmp/node_modules/rest-facade/src/Client.js:295:21
    at Request.callback (/tmp/node_modules/superagent/lib/node/index.js:688:3)
    at /tmp/node_modules/superagent/lib/node/index.js:883:18
    at Stream.<anonymous> (/tmp/node_modules/superagent/lib/node/parsers/json.js:16:7)
    at emitNone (events.js:106:13)
    at Stream.emit (events.js:208:7)
    at Unzip.<anonymous> (/tmp/node_modules/superagent/lib/node/unzip.js:53:12)
    at emitNone (events.js:111:20)
    at Unzip.emit (events.js:208:7)
    at endReadableNT (_stream_readable.js:1056:12)
    at _combinedTickCallback (internal/process/next_tick.js:138:11)
    at process._tickCallback (internal/process/next_tick.js:180:9)

Add support for Guardian config via deploy cli

Add support for Guardian config via deploy cli

Will require updates to source-control-ext-tools

Bad Request when importing clients

Hello, I am trying to export from one tenant and import into a newly created one, both within the same private instance, and getting the following error:

Bad Request: Payload validation error: 'Additional properties not allowed: owners'

I'm guessing the Management API doesn't allow for custom fields? Is there any way of getting around this limitation?

Thanks

Dealing with the client "Bad Request: Invalid grant types" error on import

(We should maybe move the content issue to a Troubleshooting section in the README)

Problem

It's possible that you have an Auth0 tenant that was created before 8 June, 2017. If so, it will likely contain clients (apps) with legacy grant types. If you use the a0deploy CLI to export those clients and then later perform an import, you may see an error message that looks like this:

2018-10-28T17:16:03.341Z - error: Problem running command import during stage processChanges when processing type clients
2018-10-28T17:16:03.341Z - error: Problem updating clients {"name":"your-app","client_id":"YOUR_APP_CLIENT_ID"}
Bad Request: Invalid grant types: http://auth0.com/oauth/legacy/grant-type/ro, http://auth0.com/oauth/legacy/grant-type/ro/jwt-bearer, http://auth0.com/oauth/legacy/grant-type/delegation/refresh_token, http://auth0.com/oauth/legacy/grant-type/delegation/id_token, http://auth0.com/oauth/legacy/grant-type/access_token

FYI: your error may only contain some of the legacy grant types shown in the above error.

Resolution

There are two ways to resolve this issue:

If you don't need those legacy grant types or you can switch to a more secure alternative to their use, then you can simply remove them from the local client configuration file (client JSON file or section in the tenant.yaml file). Then try the import again.

If it turns out you do need to use at least some of these legacy grant types, then you'll need to enable their use in your tenant settings. The three tenant settings that are associated with the legacy grant types are the following (tenant > Settings > Advanced > Migrations section):

Only enable the setting(s) you actually need if you only need a subset of the grant types.

NOTE:

If you don't see those settings in your tenant, it's because it was created after 8 June, 2017 and, therefore, you shouldn't be having this issue in the first place.

Support comparing source control config to tenant config

Should we support the ability to compare/diff your local config to what is in the auth0 tenant.

"Tell me what has changed in my production env compared to my local env"

Support env specific unique id's to config.json

Feedback from a customer POC. During export with --strip we may want to consider the ability to export the client_id to another config file. This means it can move from env to env but the client's app could be captured and injected into their app config.

The more i think about this the more i don't think it belongs in this tool. Closing for now.

Export without secrets

Hello,

Is it possible to export a yaml file stripping out the client secrets? It doesn't look like it. If not, it would be a great idea as we are looking to use an export of the current state before a deploy as an artifact for rollback and we wouldn't want it to contain sensitive info.

Thanks

Auth0 Extensions - Auth0 Deploy CLI Version1.0 Insufficient scope

Hi All,

The Auth0 Installed Extensions - Auth0 Deploy CLI Version1.0 has to be update to match Auth0 CLI 2.x so the Scope is setup right.
The Auth0 CLI for export require: export "read:rules_configs".

Here is the log output:
error: Problem running command export during stage load when processing type rulesConfigs error: {"statusCode":403,"error":"Forbidden","message":"Insufficient scope, expected any of: read:rules_configs","errorCode":"insufficient_scope"}

Error while import - Rules name pattern

I got the following error while running import command:

2018-10-28T07:29:04.135Z - error: Problem running command import 2018-10-28T07:29:04.136Z - error: Schema validation failed loading [ { "keyword": "pattern", "dataPath": ".rules[0].name", "schemaPath": "#/properties/rules/items/properties/name/pattern", "params": { "pattern": "^[^-][a-zA-Z0-9-]+[^-]$" }, "message": "should match pattern \"^[^-][a-zA-Z0-9-]+[^-]$\"" } ]

Could you change the pattern to allow spaces in the rule names as spaces were allowed when I created the rules in auth0 dashboard?

installation problem due to express-jwt

npm i -g auth0-deploy-cli doesn't complete due to express-jwt error

npm ERR! 404 Not Found: @types/[email protected]

I am using node v8

Add ability to enable and disable connections for clients

Likely this should go in the clients meta.json file

Add docs to Export

TODO:

Work out how to add some documentation to the YAML and Directory Export.

Add support for missing database connection settings

Lacking this, I can't keep my password complexity settings and/or password dictionary under revision control.

APIError: read ECONNRESET on creating client

Hi Team,

First of all awesome tool! Simply love it. Works like a charm!

The issue I am having is when I try to create clients. Note taht with the same config, I am able to create/update rules and in the same workflow I am getting error for creating clients.

The error Logs below:

2018-10-04T13:09:13.015Z - debug: Creating clients...
2018-10-04T13:09:13.017Z - debug: Creating clients grafana-dev: {"allowed_clients":[],"allowed_logout_urls":[],"allowed_origins":[],"app_type":"regular_web","callbacks":["https://grafana.horizondev.cloud/login/generic_oauth"],"cross_origin_auth":false,"custom_login_page_on":true,"description":"","grant_types":["authorization_code","implicit","refresh_token","client_credentials"],"jwt_configuration":{"alg":"RS256","lifetime_in_seconds":36000},"logo_uri":"","name":"grafana-dev","oidc_conformant":true,"sso":false,"sso_disabled":false,"token_endpoint_auth_method":"client_secret_post","web_origins":[]}
2018-10-04T13:09:13.599Z - debug: Error: read ECONNRESET
2018-10-04T13:09:13.602Z - debug: StackTrace: APIError: read ECONNRESET
    at C:\Users\z003rpaf\AppData\Roaming\npm\node_modules\auth0-deploy-cli\node_modules\rest-facade\src\Client.js:358:22
    at Request.callback (C:\Users\z003rpaf\AppData\Roaming\npm\node_modules\auth0-deploy-cli\node_modules\superagent\lib\node\index.js:728:3)
    at ClientRequest.req.once.err (C:\Users\z003rpaf\AppData\Roaming\npm\node_modules\auth0-deploy-cli\node_modules\superagent\lib\node\index.js:647:10)
    at Object.onceWrapper (events.js:315:30)
    at emitOne (events.js:116:13)
    at ClientRequest.emit (events.js:211:7)
    at TLSSocket.socketErrorListener (_http_client.js:387:9)
    at emitOne (events.js:116:13)
    at TLSSocket.emit (events.js:211:7)
    at emitErrorNT (internal/streams/destroy.js:66:8)
    at _combinedTickCallback (internal/process/next_tick.js:139:11)
    at process._tickCallback (internal/process/next_tick.js:181:9)
2018-10-04T13:09:13.607Z - debug: Sending progress to Slack.
2018-10-04T13:09:13.610Z - error: Exiting due to error: "read ECONNRESET"
2018-10-04T13:09:13.612Z - error: APIError: read ECONNRESET
    at C:\Users\z003rpaf\AppData\Roaming\npm\node_modules\auth0-deploy-cli\node_modules\rest-facade\src\Client.js:358:22
    at Request.callback (C:\Users\z003rpaf\AppData\Roaming\npm\node_modules\auth0-deploy-cli\node_modules\superagent\lib\node\index.js:728:3)
    at ClientRequest.req.once.err (C:\Users\z003rpaf\AppData\Roaming\npm\node_modules\auth0-deploy-cli\node_modules\superagent\lib\node\index.js:647:10)
    at Object.onceWrapper (events.js:315:30)
    at emitOne (events.js:116:13)
    at ClientRequest.emit (events.js:211:7)
    at TLSSocket.socketErrorListener (_http_client.js:387:9)
    at emitOne (events.js:116:13)
    at TLSSocket.emit (events.js:211:7)
    at emitErrorNT (internal/streams/destroy.js:66:8)
    at _combinedTickCallback (internal/process/next_tick.js:139:11)
    at process._tickCallback (internal/process/next_tick.js:181:9)

Updating enable_sso flag is not allowed

We encounter this error while trying to import an exported tenant configuration from the console. Posting it here since I haven't seen any references to the enable_sso flag problem anywhere in the docs.

2018-11-27T23:39:00.465Z - error: Updating the enable_sso flag is not allowed.

Command for exporting tenant:-

a0deploy export -c config.json  -f directory -o tenant/directory

Command for importing tenant:-

a0deploy import -c config.json -i tenant/directory

How to reproduce ?

• Create a new tenant in auth0
• Export the tenant using the deploy CLI (any format yaml or directory will do)
• Try to reimport the same config using the auth0-deploy-cli into the same or a different tenant.
• The import will fail with the above error.

Work around:-

• Edit the generated tenant config file (tenant.json or tenant.yml)
• Delete the enable_sso line in flags. If enable_sso is the only flag, then delete the whole flags entry.
• Reimport the config, it should successfully import now.

deploy - should be array

First, thanks for the update to this library. The new changes are welcome and come along way to filling in gaps from the past.

Using the new version, and having performed an export of my tenant and then using the same export I'm unable to perform a deployment. I've reviewed the folder structure, and its' right and matches examples. I've dug into it for a while, and surprisingly I did get it to work once or twice, but I'll be damned if I didn't reset things to try again and I cannot for the life of me get it working again.

(node:10297) UnhandledPromiseRejectionWarning: Error: Schema validation failed loading [ warning.js:18 { "keyword": "type", "dataPath": ".exclude.rules", "schemaPath": "#/properties/exclude/properties/rules/type", "params": { "type": "array" }, "message": "should be array" } ]

Do you have any ideas what could be holding me up, and if not what other details can i provide? I am using 2.2.0 of the auth0-deploy-cli. I've made sure npm isn't resolving an old version.

Thanks in advanced.

The slack message is a bit funky

I see something like this:

auth0-deployments APP [21:18]
Source-control to Auth0 Deployment (<undefined/login|Details>)
Tool: Auth0 Deploy CLI
Host: e4900587-aa24-4e1d-4eea-c40ceaf4571c
Username: root
Date/Time: 2018-04-17T19:18:33+00:00
Rules Updated: 3
Clients Updated: 9

The "undefined" comes from the WT_URL property not being set. (WT_URL is not documented in the readme.)

Also, including hints about which Auth tenant would be helpful.

Even better, an option to include whichever property from the config file or environment would be very helpful.

As a "hack" for now I am tempted to set the WT_URL config value in order to be able to see which Auth0 tenant the deploy is being done for.

AUTH0_KEYWORD_REPLACE_MAPPINGS not working in database-connections files and rules

I would like to configure a domain in the replace mappings to inject it in JS files (rules and custom database scripts). However, it doesn't seem to work.
Here is my config :

{
    "AUTH0_DOMAIN": "mydomain.auth0.com",
    "AUTH0_CLIENT_ID": "xxxxxxxxxxxxxxxxxxxxxxxxx",
    "AUTH0_CLIENT_SECRET": "xxxxxxxxxxxxxxxxxxxxx",
    "AUTH0_KEYWORD_REPLACE_MAPPINGS": {
        "PG_DOMAIN": "https://99db6f1c.ngrok.io"
    }
}

login.js :

function login(email, password, callback) {
	var gatewayURL = @@PG_DOMAIN@@;
	/* ... */

a-rule.js :

function getPGToken(user, context, callback) {
	var gatewayURL = @@PG_DOMAIN@@;
	/* ... */

In the Auth0 dashboard, the values are not replaced, hence the auth flow is broken.

Did I miss something or is it not implemented ?

Are APIs supported in this tool?

I wonder if I can use the tool with custom APIs, it doesn't mention it in the docs.

Update the configuration to allow a list of rules to be manual.

To match the extensions for github deploy and others, we should have the ability to configure a set of rules that can be ignored and not deleted without having to specify them in the repository.

Directory export fails if entity name includes `/`

In my tenant, I have a client named AD / ADFS CUSTOM DOMAIN and a0deploy failed with error as it's not escaping names properly.

    at Object.openSync (fs.js:439:3)
    at Object.writeFileSync (fs.js:1190:35)
    at clients.forEach.client (/usr/local/lib/node_modules/auth0-deploy-cli/lib/context/directory/handlers/clients.js:49:23)
    at Array.forEach (<anonymous>)
    at Object.dump (/usr/local/lib/node_modules/auth0-deploy-cli/lib/context/directory/handlers/clients.js:46:11)
    at Promise.all.Object.entries.map (/usr/local/lib/node_modules/auth0-deploy-cli/lib/context/directory/index.js:87:36)
    at Array.map (<anonymous>)
    at _default.dump (/usr/local/lib/node_modules/auth0-deploy-cli/lib/context/directory/index.js:85:58)
2019-01-28T11:46:09.280Z - error: Problem running command export
2019-01-28T11:46:09.280Z - error: Problem exporting clients```

Keyword Mappings of limited value to HTML content

Scenario

• You use the deploy-cli to deploy your custom logon page
• Your project promotes changes through a series of environments before getting to productioin
• Each environment has a different CDN for hosting css, images, scripts, etc

Ideally, in this scenario you'd want to be able to build your page to accept a Keyword Mapping to replace the CDN host address during deployment.

Something like this:

<html>
    <head>
   <script src="@@CDN_HOST@@/snazzy-login.js"></script>
   <link href="@@CDN_HOST@@/styles/login.css" rel="stylesheet" type="text/css"/>
    </head>
    <body>
      <h1> Logon! </h1>
      <img src="@@CDN_HOST@@/images/company_logo.png" />
    </body>
</html>

With a config file like this:

{
  "AUTH0_DOMAIN": "...",
  "AUTH0_CLIENT_ID": "...",
  "AUTH0_CLIENT_SECRET": "...",
  "AUTH0_KEYWORD_REPLACE_MAPPINGS": {
    "CDN_HOST": "https://prod.cdn.com"
  }
}

Unfortunately this yields extra " in the HTML when deployed eg:

href=""https://prod.cdn.com"/styles/login.css"

I assume this is because the mapping was originally written for building JSON trees like

{
  "host": @@CDN_HOST@@
}

My local testing is consistent, I'm surprised this didn't come up in #3 when @nickcoury was trying something similar?

I'm trying to replace a keyword in an HTML page and for the life of me can't get it to work as the documentation shows.

Am I imagining things?

Add support for email providers

As a user I would like to deploy my email providers and templates via the deployment CLI.

Externalize secrets and sensitive values

This is less of an issue and more of an awareness deal. I created an NPM module that will take care of this via secret manager, as well as adding some double hash lockups within the configuration file itself.

https://github.com/matt-filion/auth0-deploy-cli-config-values/blob/master/README.md

CLI fails on .DS_Store

When trying to run the CLI it will fail on direct/.DS_Store on OSX.

Return code is always 0 - even in case of error

When I run a0deploy with a configuration that is incorrect, a0deploy returns 0. It should return an error code instead.

By returning 0 every time, pipelining tools won't stop if the deployment failed.

Getting clientGrants with audiences that do not correspond to an API when exporting

Hello,

I am using the tool to export an existing tenant configuration from an instance using the appliance deployment model, but when I try to import this configuration to another tenant, I get a few errors because some client grants use an audience that does not match any identifier. The errors look like Not Found: No resource with identifier https://foo/bar/
I am aware of issue #29 but that is not my case as it is not the Management API those grants are targeting. Manually inspecting the tenant APIs also did not reveal any API using that audience either. My understanding is that clientGrants could only be created against an existing API. So I am unsure how/why those grants get exported. Could it happen that the API was removed but not the grants targeting it? And in that case, would I be safe in removing the offending clientGrants?

Thanks.

It would be great to have support for updating Account Settings Level Allowed Logout Urls

It would be great to have support for updating Account Settings Level Allowed Logout Urls

Normal database connections not importing or exporting correctly

Import

If you're attempting to import a "normal" (i.e. not a custom) database connection, the CLI sets the customScripts option to a value of {} instead of null. Auth0 seems to treat this as if the database connection is a custom DB connection.

The result is that if you attempt to create a user in that connection, you get an error. In the Dashboard that error looks like this:

For import, the issue appears to be here for YAML and here for directory.

Export

There seems to be a related issue for export. If I export a regular database connection, the resulting YAML carries the customScripts: {} attribute in the options. It should instead be empty or null. Note: I think there's some sort of schema validation is preventing it from having a null value.

Update Email Templates

We would also love to be able to update Email Templates

No resource with identifier No resource with identifier Auth0 Management API

I can't grant a client access to the Auth0 management API by specifying, in clients/zzzz.meta.json, either:

• grants["Auth0 Management API"]
• grants["278ad02cf7254e85b03e29ee"] where that's the ID of the management API for that tenant

a0deploy crashes out with:

2018-04-24T04:01:44.709Z - error: Exiting due to error: "No resource with identifier Auth0 Management API"
2018-04-24T04:01:44.710Z - error: Not Found: No resource with identifier Auth0 Management API

GET https://xxxx.yy.auth0.com/api/v2/resource-servers → 200 OK with:

[
  {
    "id": "278ad02cf7254e85b03e29ee",
    "name": "Auth0 Management API",
    "identifier": "https://xxxx.yy.auth0.com/api/v2/",
…

Workaround: using identifier does work, so you can wrap your tenant URL's api/v2 as above and substitute it with AUTH0_KEYWORD_REPLACE_MAPPINGS in your configuration JSON:

{
  "AUTH0_DOMAIN": "xxxx.yy.auth0.com",
  "AUTH0_CLIENT_ID": "…",
  "AUTH0_KEYWORD_REPLACE_MAPPINGS": {
    "AUTH0_MANAGEMENT_API_IDENTIFIER": "https://xxxx.yy.auth0.com/api/v2/",
…

… then, in your client.meta.json:

{
  "grants": {
    "##AUTH0_MANAGEMENT_API_IDENTIFIER##": [
      "read:users"
    ]
  }
}

AUTH0_EXCLUDED_RULES will not preventing creating rules that are excluded

From the readme:

AUTH0_EXCLUDED_RULES
This is a list of rule names that should be ignored by the deploy CLI. It will not delete, update or create rules that match those names.

But looking at the "updateRule" method in "auth0-source-control-extension-tools" repo, the excluding of the script for certain rule happens after the creation of the rule, code here. It seems like L111 already created the rule, which makes L114-L117 having no effect.

As a result of the above, the "AUTH0_EXCLUDED_RULES" will not prevent creating new rules that are excluded in the config.

Also, based on the current implementation of "applyMetadata" method here, it doesn't care about the "isExcluded" variable, which means, when excluding an existing rule, if the rule was turned off in the admin console, but was set to enabled: true in the metadata, the deploy tool will actually turn it on despite it's excluded.

Is this expected behavior?

Add support for creating Hooks

Can this add support for creating hooks? Today hooks can be deployed via the Webtask API or utilizing the wt-cli or the Auth0 CLI that is in beta and ships with wt-cli via npm.

Rules exporting with ID's

Its a bit unclear how these should be handled. I understand the value in the ID being present, in terms of what the tool needs, but the exported YAML or JSON having an ID adds confusion as to how you would add new rules. Docs around the ID being OK to remove, or it not being in included if not required, will help avoid this confusion.

enabled_clients not working in database.json

After running an export of my tenant's configuration with the a0deploy tool and subsequently re-importing the results, I've found that the enabled_clients field of the /database-connections/dbname/database.json file is apparently ignored. The export filled this array with client names, and I have tried replacing them with their associated IDs, however in both instances after a deploy occurs the applications have all been disabled in the connection.