auth0-deploy-cli 7.13.1 → 7.14.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.github/dependabot.yml +3 -0
- package/CHANGELOG.md +16 -1
- package/README.md +121 -65
- package/docs/available-resource-config-formats.md +19 -0
- package/docs/configuring-the-deploy-cli.md +140 -0
- package/docs/excluding-from-management.md +81 -0
- package/docs/how-to-contribute.md +49 -0
- package/docs/keyword-replacement.md +45 -0
- package/docs/multi-environment-workflow.md +98 -0
- package/docs/terraform-provider.md +20 -0
- package/docs/using-as-cli.md +89 -0
- package/docs/using-as-node-module.md +114 -0
- package/lib/commands/import.d.ts +2 -0
- package/lib/commands/import.js +36 -1
- package/lib/context/yaml/handlers/pages.js +1 -1
- package/lib/tools/auth0/handlers/tenant.d.ts +12 -1
- package/lib/tools/auth0/handlers/tenant.js +39 -4
- package/lib/types.d.ts +4 -5
- package/lib/utils.d.ts +1 -1
- package/package.json +3 -3
package/.github/dependabot.yml
CHANGED
package/CHANGELOG.md
CHANGED
|
@@ -7,6 +7,17 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
|
|
|
7
7
|
|
|
8
8
|
## [Unreleased]
|
|
9
9
|
|
|
10
|
+
## [7.14.0] - 2022-06-27
|
|
11
|
+
|
|
12
|
+
### Added
|
|
13
|
+
|
|
14
|
+
- Validation to detect unreplaced keyword mappings during import [#591]
|
|
15
|
+
|
|
16
|
+
### Fixed
|
|
17
|
+
|
|
18
|
+
- Detect and prevent `You are not allowed to set flag '<SOME_FLAG>' for this tenant.` errors when erroneously setting non-configurable migration flag [#590]
|
|
19
|
+
- Crash when attempting to create page templates from undefined value [#592]
|
|
20
|
+
|
|
10
21
|
## [7.13.1] - 2022-06-13
|
|
11
22
|
|
|
12
23
|
### Fixed
|
|
@@ -776,7 +787,11 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
|
|
|
776
787
|
[#554]: https://github.com/auth0/auth0-deploy-cli/issues/554
|
|
777
788
|
[#563]: https://github.com/auth0/auth0-deploy-cli/issues/563
|
|
778
789
|
[#577]: https://github.com/auth0/auth0-deploy-cli/issues/577
|
|
779
|
-
[
|
|
790
|
+
[#590]: https://github.com/auth0/auth0-deploy-cli/issues/590
|
|
791
|
+
[#591]: https://github.com/auth0/auth0-deploy-cli/issues/591
|
|
792
|
+
[#592]: https://github.com/auth0/auth0-deploy-cli/issues/592
|
|
793
|
+
[unreleased]: https://github.com/auth0/auth0-deploy-cli/compare/v7.14.0...HEAD
|
|
794
|
+
[7.14.0]: https://github.com/auth0/auth0-deploy-cli/compare/v7.13.1...v7.14.0
|
|
780
795
|
[7.13.1]: https://github.com/auth0/auth0-deploy-cli/compare/v7.13.0...v7.13.1
|
|
781
796
|
[7.13.0]: https://github.com/auth0/auth0-deploy-cli/compare/v7.12.3...v7.13.0
|
|
782
797
|
[7.12.3]: https://github.com/auth0/auth0-deploy-cli/compare/v7.12.2...v7.12.3
|
package/README.md
CHANGED
|
@@ -1,65 +1,121 @@
|
|
|
1
|
-
|
|
2
|
-
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
-
|
|
17
|
-
-
|
|
18
|
-
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
- [
|
|
23
|
-
- [
|
|
24
|
-
- [
|
|
25
|
-
- [
|
|
26
|
-
- [
|
|
27
|
-
- [
|
|
28
|
-
- [
|
|
29
|
-
- [ ]
|
|
30
|
-
- [
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
1
|
+
<div align="center">
|
|
2
|
+
<h1>Auth0 Deploy CLI</h1>
|
|
3
|
+
|
|
4
|
+
[](https://badge.fury.io/js/auth0-deploy-cli)
|
|
5
|
+
[](https://circleci.com/gh/auth0/auth0-deploy-cli/tree/master)
|
|
6
|
+
[](https://opensource.org/licenses/MIT)
|
|
7
|
+
|
|
8
|
+
</div>
|
|
9
|
+
|
|
10
|
+
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.
|
|
11
|
+
|
|
12
|
+
**Supported resource types:** actions, branding, client grants, clients (applications), connections, custom domains, email templates, emails, grants, guardian, hook secrets, hooks, log streams, migrations, organizations, pages, prompts, resource servers (APIs), roles, rules, rules configs, tenant settings, themes.
|
|
13
|
+
|
|
14
|
+
## Highlights
|
|
15
|
+
|
|
16
|
+
- **Multi-Environment Oriented:** Designed to help you test your applications' Auth0 integrations from feature branch all the way to production.
|
|
17
|
+
- **Keyword Replacement:** Shared resource configurations across all environments with dynamic keyword replacement.
|
|
18
|
+
- **Versatile:** Integrate into your CI/CD workflows either as a CLI or as a Node module.
|
|
19
|
+
|
|
20
|
+
## Documentation
|
|
21
|
+
|
|
22
|
+
- [Using as a CLI](docs/using-as-cli.md)
|
|
23
|
+
- [Using as a Node Module](docs/using-as-node-module.md)
|
|
24
|
+
- [Configuring the Deploy CLI](docs/configuring-the-deploy-cli.md)
|
|
25
|
+
- [Keyword Replacement](docs/keyword-replacement.md)
|
|
26
|
+
- [Incorporating Into Multi-environment Workflows](docs/multi-environment-workflow.md)
|
|
27
|
+
- [Excluding Resources From Management](docs/excluding-from-management.md)
|
|
28
|
+
- [Available Resource Formats](docs/available-resource-config-formats.md)
|
|
29
|
+
- [Terraform Provider](docs/terraform-provider.md)
|
|
30
|
+
- [How to Contribute](docs/how-to-contribute.md)
|
|
31
|
+
|
|
32
|
+
## Getting Started
|
|
33
|
+
|
|
34
|
+
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:
|
|
35
|
+
|
|
36
|
+
1. [Create a Dedicated Auth0 Application](#create-a-dedicated-auth0-application)
|
|
37
|
+
2. [Configure the Deploy CLI](#configure-the-deploy-cli)
|
|
38
|
+
3. [Calling the Deploy CLI](#calling-the-deploy-cli)
|
|
39
|
+
|
|
40
|
+
> ⚠️ **NOTE:** This tool can be destructive to your Auth0 tenant. It is recommended to be familiar with the [`AUTH0_ALLOW_DELETE` configuration](docs/configuring-the-deploy-cli.md#auth0allowdelete) and to test on development tenants prior to using in production.
|
|
41
|
+
|
|
42
|
+
### Prerequisites
|
|
43
|
+
|
|
44
|
+
- [Node](https://nodejs.dev/) version 10 or greater
|
|
45
|
+
- [Auth0 Tenant](https://auth0.com/)
|
|
46
|
+
|
|
47
|
+
### Install the Deploy CLI
|
|
48
|
+
|
|
49
|
+
To run as a standalone command-line tool:
|
|
50
|
+
|
|
51
|
+
```shell
|
|
52
|
+
npm install -g auth0-deploy-cli
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
### Create a dedicated Auth0 Application
|
|
56
|
+
|
|
57
|
+
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.
|
|
58
|
+
|
|
59
|
+
1. From the Auth0 dashboard, navigate to **Applications > Applications**
|
|
60
|
+
2. Click “Create Application”
|
|
61
|
+
3. On Create application page:
|
|
62
|
+
a. Name it “Deploy CLI” or similar
|
|
63
|
+
b. Select “Machine to Machine Applications” as application type
|
|
64
|
+
c. Click “Create”
|
|
65
|
+
4. On the “Authorize Machine to Machine Application” page
|
|
66
|
+
a. Select “Auth0 Management API”
|
|
67
|
+
b. Select the appropriate permissions for the resources you wish to manage. Refer to the [Client Scopes](#client-scopes) section for more information.
|
|
68
|
+
c. Click “Authorize”
|
|
69
|
+
|
|
70
|
+
#### Client Scopes
|
|
71
|
+
|
|
72
|
+
The designated application needs to be granted scopes in order to allow the Deploy CLI to execute Management operations.
|
|
73
|
+
|
|
74
|
+
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.
|
|
75
|
+
|
|
76
|
+
### Configure the Deploy CLI
|
|
77
|
+
|
|
78
|
+
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](docs/configuring-the-deploy-cli.md) page. However, for this example, the simplest way to get going is by setting the following environment variables:
|
|
79
|
+
|
|
80
|
+
- `AUTH0_DOMAIN`
|
|
81
|
+
- `AUTH0_CLIENT_ID`
|
|
82
|
+
- `AUTH0_CLIENT_SECRET`
|
|
83
|
+
|
|
84
|
+
These values can be found in the “Settings” tab within the Auth0 application created in the previous step.
|
|
85
|
+
|
|
86
|
+
### Calling the Deploy CLI
|
|
87
|
+
|
|
88
|
+
Finally, with above complete, the Deploy CLI export command can be run:
|
|
89
|
+
|
|
90
|
+
```shell
|
|
91
|
+
a0deploy export --format=yaml --output_folder=local
|
|
92
|
+
```
|
|
93
|
+
|
|
94
|
+
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:
|
|
95
|
+
|
|
96
|
+
```shell
|
|
97
|
+
a0deploy import -c=config.json --input_file local/tenant.yaml
|
|
98
|
+
```
|
|
99
|
+
|
|
100
|
+
## Issue Reporting
|
|
101
|
+
|
|
102
|
+
For general support or usage questions, use the [Auth0 Community](https://community.auth0.com/tag/deploy-cli) forums or raise a [support ticket](https://support.auth0.com/). Only [raise an issue](https://github.com/auth0/auth0-deploy-cli/issues) if you have found a bug or want to request a feature.
|
|
103
|
+
|
|
104
|
+
**Do not report security vulnerabilities on the public GitHub issue tracker.** The [Responsible Disclosure Program](https://auth0.com/responsible-disclosure-policy) details the procedure for disclosing security issues.
|
|
105
|
+
|
|
106
|
+
## What is Auth0?
|
|
107
|
+
|
|
108
|
+
Auth0 helps you to:
|
|
109
|
+
|
|
110
|
+
- Add authentication with [multiple sources](https://auth0.com/docs/authenticate/identity-providers), either social identity providers such as **Google, Facebook, Microsoft Account, LinkedIn, GitHub, Twitter, Box, Salesforce** (amongst others), or enterprise identity systems like **Windows Azure AD, Google Apps, Active Directory, ADFS, or any SAML identity provider**.
|
|
111
|
+
- Add authentication through more traditional **[username/password databases](https://auth0.com/docs/authenticate/database-connections/custom-db)**.
|
|
112
|
+
- Add support for **[linking different user accounts](https://auth0.com/docs/manage-users/user-accounts/user-account-linking)** with the same user.
|
|
113
|
+
- Support for generating signed [JSON Web Tokens](https://auth0.com/docs/secure/tokens/json-web-tokens) to call your APIs and **flow the user identity** securely.
|
|
114
|
+
- Analytics of how, when, and where users are logging in.
|
|
115
|
+
- Pull data from other sources and add it to the user profile through [JavaScript Actions](https://auth0.com/docs/customize/actions).
|
|
116
|
+
|
|
117
|
+
**Why Auth0?** Because you should save time, be happy, and focus on what really matters: building your product.
|
|
118
|
+
|
|
119
|
+
## License
|
|
120
|
+
|
|
121
|
+
This project is licensed under the MIT license. See the [LICENSE](LICENSE) file for more information.
|
|
@@ -0,0 +1,19 @@
|
|
|
1
|
+
# Available Resource Config Formats
|
|
2
|
+
|
|
3
|
+
Auth0 resource state is expressed in two available different configuration file formats: YAML and JSON (aka “directory”). When using the Deploy CLI’s export command, you will be prompted with the choice of one versus the other.
|
|
4
|
+
|
|
5
|
+
## YAML
|
|
6
|
+
|
|
7
|
+
The YAML format is expressed mostly as a flat `tenant.yaml` file with supplemental code files for resources like actions and email templates. The single file makes tracking changes over time in version control more straightforward. Additionally, the single file eliminates a bit of ambiguity with directory and file names, which may not be immediately obvious.
|
|
8
|
+
|
|
9
|
+
## Directory (JSON)
|
|
10
|
+
|
|
11
|
+
The directory format separates resource types into separate directories, with each single resource living inside a dedicated JSON file. This format allows for easier conceptual separation between each type of resource as well as the individual resources themselves. Also, the Deploy CLI closely mirrors the data shapes defined in the [Auth0 Management API](https://auth0.com/docs/api/management/v2), so referencing the JSON examples in the docs may provide useful when using this format.
|
|
12
|
+
|
|
13
|
+
## How to Choose
|
|
14
|
+
|
|
15
|
+
The decision to select which format to use should be primarily made off of preference. Both formats are tenable solutions that achieve the same task, but with subtly different strengths and weaknesses described above. Be sure to evaluate each in the context of your context. Importantly, **this choice is not permanent**, and switching from one to the other via the import command is an option at your disposal.
|
|
16
|
+
|
|
17
|
+
---
|
|
18
|
+
|
|
19
|
+
[[table of contents]](../README.md#documentation)
|
|
@@ -0,0 +1,140 @@
|
|
|
1
|
+
# Configuring the Deploy CLI
|
|
2
|
+
|
|
3
|
+
Configuring the Deploy’s CLI is essential for establishing Auth0 credentials as well as generally modifying the behavior of the tool to your specific needs. There are two ways the Deploy CLI can be configured:
|
|
4
|
+
|
|
5
|
+
- Configuration file (`config.json`)
|
|
6
|
+
- Environment variables
|
|
7
|
+
|
|
8
|
+
## Configuration file
|
|
9
|
+
|
|
10
|
+
A standalone JSON file can be used to configure Deploy CLI. This file will usually reside in the root directory of your project and be called `config.json`.
|
|
11
|
+
|
|
12
|
+
Example **config.json** file:
|
|
13
|
+
|
|
14
|
+
```json
|
|
15
|
+
{
|
|
16
|
+
"AUTH0_DOMAIN": "<YOUR_TENANT_DOMAIN>",
|
|
17
|
+
"AUTH0_CLIENT_ID": "<YOUR_CLIENT_ID>",
|
|
18
|
+
"AUTH0_ALLOW_DELETE": false
|
|
19
|
+
}
|
|
20
|
+
```
|
|
21
|
+
|
|
22
|
+
> ⚠️ **NOTE:** Hard-coding credentials is not recommended, and risks secret leakage should this file ever be committed to a public version control system. Instead, passing credentials as [environment variables](#Environment variables) is considered best practice.
|
|
23
|
+
|
|
24
|
+
### Environment variables
|
|
25
|
+
|
|
26
|
+
By default, the Deploy CLI ingests environment variables, providing the ability to pass credentials and other configurations to the tool without needing to publish to the `config.json` file. Environment variables can either be used to augment the `config.json` file or replace it altogether depending on the project needs.
|
|
27
|
+
|
|
28
|
+
Non-primitive configuration values like `AUTH0_KEYWORD_MAPPING` and `AUTH0_EXCLUDED` can also be passed in through environment variables so long as these values are properly serialized JSON.
|
|
29
|
+
|
|
30
|
+
To **disable** the consumption of environment variables for either the `import` or `export` commands, pass the `--env=false` argument.
|
|
31
|
+
|
|
32
|
+
#### Examples
|
|
33
|
+
|
|
34
|
+
```shell
|
|
35
|
+
# Deploying configuration for YAML formats without a config.json file
|
|
36
|
+
export AUTH0_DOMAIN=<YOUR_AUTH0_DOMAIN>
|
|
37
|
+
export AUTH0_CLIENT_ID=<YOUR_CLIENT_ID>
|
|
38
|
+
export AUTH0_CLIENT_SECRET=<YOUR_CLIENT_SECRET>
|
|
39
|
+
|
|
40
|
+
a0deploy import --input_file=local/tenant.yaml
|
|
41
|
+
|
|
42
|
+
# Disable environment variable ingestion
|
|
43
|
+
a0deploy export -c=config.json --format=yaml --output_folder=local --env=false
|
|
44
|
+
|
|
45
|
+
# Non-primitive configuration values
|
|
46
|
+
export AUTH0_EXCLUDED='["actions","organizations"]'
|
|
47
|
+
export AUTH0_KEYWORD_REPLACE_MAPPINGS='{"ENVIRONMENT":"dev"}'
|
|
48
|
+
a0deploy export -c=config.json --format=yaml --output_folder=local
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
## Available Configuration Properties
|
|
52
|
+
|
|
53
|
+
### `AUTH0_DOMAIN`
|
|
54
|
+
|
|
55
|
+
String. The domain of the target Auth0 tenant.
|
|
56
|
+
|
|
57
|
+
### `AUTH0_CLIENT_ID`
|
|
58
|
+
|
|
59
|
+
String. The ID of the designated Auth0 application used to make API requests.
|
|
60
|
+
|
|
61
|
+
### `AUTH0_CLIENT_SECRET`
|
|
62
|
+
|
|
63
|
+
String. The secret of the designated Auth0 application used to make API requests.
|
|
64
|
+
|
|
65
|
+
### `AUTH0_ACCESS_TOKEN`
|
|
66
|
+
|
|
67
|
+
String. Short-lived access token for Management API from designated Auth0 application. Can be used in replacement to client ID and client secret combination.
|
|
68
|
+
|
|
69
|
+
### `AUTH0_ALLOW_DELETE`
|
|
70
|
+
|
|
71
|
+
Boolean. When enabled, will allow the tool to delete resources. Default: `false`.
|
|
72
|
+
|
|
73
|
+
### `AUTH0_EXCLUDED`
|
|
74
|
+
|
|
75
|
+
Array of strings. Excludes entire resource types from being managed, bi-directionally. See also: [excluding resources from management](excluding-from-management.md). Possible values: `actions`, `attackProtection`, `branding`, `clientGrants`, `clients`, `connections`, `customDomains`, `databases`, `emailProvider`, `emailTemplates`, `guardianFactorProviders`, `guardianFactorTemplates`, `guardianFactors`, `guardianPhoneFactorMessageTypes`, `guardianPhoneFactorSelectedProvider`, `guardianPolicies`, `hooks`, `logStreams`, `migrations`, `organizations`, `pages`, `prompts`, `resourceServers`, `roles`, `rules`, `rulesConfigs`, `tenant`, `triggers`
|
|
76
|
+
|
|
77
|
+
#### Example
|
|
78
|
+
|
|
79
|
+
```json
|
|
80
|
+
{
|
|
81
|
+
"AUTH0_EXCLUDED": ["organizations", "connections", "hooks"]
|
|
82
|
+
}
|
|
83
|
+
```
|
|
84
|
+
|
|
85
|
+
### `AUTH0_KEYWORD_REPLACE_MAPPINGS`
|
|
86
|
+
|
|
87
|
+
Mapping of specific keywords to facilities dynamic replacement. See also: [keyword replacement](keyword-replacement.md).
|
|
88
|
+
|
|
89
|
+
#### Example
|
|
90
|
+
|
|
91
|
+
```json
|
|
92
|
+
{
|
|
93
|
+
"ENVIRONMENT": "DEV",
|
|
94
|
+
"ALLOWED_ORIGINS": ["https://dev.test-site.com", "localhost"]
|
|
95
|
+
}
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
### `AUTH0_EXPORT_IDENTIFIERS`
|
|
99
|
+
|
|
100
|
+
Boolean. When enabled, will return identifiers of all resources. May be useful for certain debugging or record-keeping scenarios within a single-tenant context. Default: `false`.
|
|
101
|
+
|
|
102
|
+
### `EXCLUDED_PROPS`
|
|
103
|
+
|
|
104
|
+
Provides ability to exclude any unwanted properties from management.
|
|
105
|
+
|
|
106
|
+
#### Example
|
|
107
|
+
|
|
108
|
+
```json
|
|
109
|
+
{
|
|
110
|
+
"connections": ["options.twilio_token"]
|
|
111
|
+
}
|
|
112
|
+
```
|
|
113
|
+
|
|
114
|
+
### `AUTH0_AUDIENCE`
|
|
115
|
+
|
|
116
|
+
String. Separate value from audience value while retrieving an access token for management API. Useful when default Management API endpoints are not publicly exposed.
|
|
117
|
+
|
|
118
|
+
### `AUTH0_EXCLUDED_RULES`
|
|
119
|
+
|
|
120
|
+
Array of strings. Excludes the management of specific rules by ID. **Note:** This configuration may be subject to deprecation in the future. See: [excluding resources from management](excluding-from-management.md).
|
|
121
|
+
|
|
122
|
+
### `AUTH0_EXCLUDED_CLIENTS`
|
|
123
|
+
|
|
124
|
+
Array of strings. Excludes the management of specific clients by ID. **Note:** This configuration may be subject to deprecation in the future. See: [excluding resources from management](excluding-from-management.md).
|
|
125
|
+
|
|
126
|
+
### `AUTH0_EXCLUDED_DATABASES`
|
|
127
|
+
|
|
128
|
+
Array of strings. Excludes the management of specific databases by ID. **Note:** This configuration may be subject to deprecation in the future. See: [excluding resources from management](excluding-from-management.md).
|
|
129
|
+
|
|
130
|
+
### `AUTH0_EXCLUDED_CONNECTIONS`
|
|
131
|
+
|
|
132
|
+
Array of strings. Excludes the management of specific connections by ID. **Note:** This configuration may be subject to deprecation in the future. See: [excluding resources from management](excluding-from-management.md).
|
|
133
|
+
|
|
134
|
+
### `AUTH0_EXCLUDED_RESOURCE_SERVERS`
|
|
135
|
+
|
|
136
|
+
Array of strings. Excludes the management of specific resource servers by ID. **Note:** This configuration may be subject to deprecation in the future. See: [excluding resources from management](excluding-from-management.md).
|
|
137
|
+
|
|
138
|
+
---
|
|
139
|
+
|
|
140
|
+
[[table of contents]](../README.md#documentation)
|
|
@@ -0,0 +1,81 @@
|
|
|
1
|
+
# Excluding Resources From Management
|
|
2
|
+
|
|
3
|
+
In many cases, you may find it useful to exclude resources from being managed. This could be because your tenant has a large number of a particular resource and thus it is operationally burdensome to manage. Other times, you may wish to exclude them as your development workflow only pertains to a specific subset of resources and you’d like to omit all other resources for performance. Regardless of the use case, there are several options available for expressing exclusions in the Deploy CLI.
|
|
4
|
+
|
|
5
|
+
## Excluding entire resources by type
|
|
6
|
+
|
|
7
|
+
For more complex tenants, you may find yourself wanting to omit entire resource types. Some common use cases for wanting this capability:
|
|
8
|
+
|
|
9
|
+
- Enterprise tenant with thousands of organizations, managing all would be operationally burdensome
|
|
10
|
+
- CI/CD process only focuses on managing roles, you may wish to exclude all others
|
|
11
|
+
- Feature development pertains to hook, you may wish to temporarily exclude all others to optimize performance
|
|
12
|
+
|
|
13
|
+
This type of exclusion is expressed by passing an array of resource names into the `AUTH0_EXCLUDED` configuration property. This exclusion works **bi-directionally**, that is, both when export from Auth0 and importing to Auth0, regardless if resource configuration files exist or not.
|
|
14
|
+
|
|
15
|
+
All supported resource values for exclusion:
|
|
16
|
+
|
|
17
|
+
`actions`, `attackProtection`, `branding`, `clientGrants`, `clients`, `connections`, `customDomains`, `databases`, `emailProvider`, `emailTemplates`, `guardianFactorProviders`, `guardianFactorTemplates`, `guardianFactors`, `guardianPhoneFactorMessageTypes`, `guardianPhoneFactorSelectedProvider`, `guardianPolicies`, `hooks`, `logStreams`, `migrations`, `organizations`, `pages`, `prompts`, `resourceServers`, `roles`, `rules`, `rulesConfigs`, `tenant`, `triggers`
|
|
18
|
+
|
|
19
|
+
### Example
|
|
20
|
+
|
|
21
|
+
The following example excludes `clients`, `connections`, `databases` and `organizations` from being managed by the Deploy CLI. However, this example is arbitrary and your use case may require you to exclude less or more types.
|
|
22
|
+
|
|
23
|
+
```json
|
|
24
|
+
{
|
|
25
|
+
"AUTH0_DOMAIN": "example-site.us.auth0.com",
|
|
26
|
+
"AUTH0_CLIENT_ID": "<YOUR_AUTH0_CLIENT_ID>",
|
|
27
|
+
"AUTH0_EXCLUDED": ["clients", "connections", "databases", "organizations"]
|
|
28
|
+
}
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
## Excluding single resources by ID
|
|
32
|
+
|
|
33
|
+
Some resource types support exclusions of individual resource by ID. This is primarily useful if you work in a multi-environment context and wish to omit a production single, specific resource from your lower-level environments. The by-ID method of exclusion is supported for rules, clients, databases, connections and resource servers with the `AUTH0_EXCLUDED_RULES` ,`AUTH0_EXCLUDED_CLIENTS`, `AUTH0_EXCLUDED_DATABASES`, `AUTH0_EXCLUDED_CONNECTIONS`, `AUTH0_EXCLUDED_RESOURCE_SERVERS` configuration values respectively.
|
|
34
|
+
|
|
35
|
+
```json
|
|
36
|
+
{
|
|
37
|
+
"AUTH0_DOMAIN": "example-site.us.auth0.com",
|
|
38
|
+
"AUTH0_CLIENT_ID": "<YOUR_AUTH0_CLIENT_ID>",
|
|
39
|
+
"AUTH0_EXCLUDED_CLIENTS": ["PdmQpGy72sHksV6ueVNZVrV4GDlDDm76"],
|
|
40
|
+
"AUTH0_EXCLUDED_CONNECTIONS": ["con_O1H3KyRMFP1IWRq3", "con_9avEYuj19ihqKBOs"]
|
|
41
|
+
}
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
> ⚠️ **NOTE:** Excluding resources by ID is being considered for deprecation in future major versions. See the [resource exclusion proposal](https://github.com/auth0/auth0-deploy-cli/issues/451) for more details.
|
|
45
|
+
|
|
46
|
+
## Omitted vs excluded vs empty
|
|
47
|
+
|
|
48
|
+
The above sections pertain to exclusion which forcefully ignore configurations bi-directionally. It is worth noting similar but very different concepts: “omissions” and “empty” states.
|
|
49
|
+
|
|
50
|
+
### Omission
|
|
51
|
+
|
|
52
|
+
Resource configuration that is absent, either intentionally or unintentionally, will be skipped during import. That is, if you resource configuration were deleted, those configurations would be skipped during import and will not alter the remote tenant state. There is no concept of omission for exporting; unless specifically excluded, all your tenant configurations will be written to resource configuration files.
|
|
53
|
+
|
|
54
|
+
### Example of omission
|
|
55
|
+
|
|
56
|
+
```yaml
|
|
57
|
+
roles: # roles configuration is not omitted
|
|
58
|
+
- name: Admin
|
|
59
|
+
description: Can read and write things
|
|
60
|
+
permissions: []
|
|
61
|
+
- name: Reader
|
|
62
|
+
description: Can only read things
|
|
63
|
+
permissions: []
|
|
64
|
+
# The omission of all other configurations means they'll be skipped over
|
|
65
|
+
```
|
|
66
|
+
|
|
67
|
+
### Empty
|
|
68
|
+
|
|
69
|
+
Resource configuration that is explicitly defined as empty. For set-based configurations like hooks, organizations and actions, setting these configurations to an empty set expresses an intentional emptying of those resources. In practice, this would signal a deletion, so long as the [`AUTH0_ALLOW_DELETE` deletion configuration property](configuring-the-deploy-cli.md#AUTH0_ALLOW_DELETE) is enabled. For non-set-based resource configuration like tenant and branding, the concept of emptiness does not apply, will not trigger any deletions or removals.
|
|
70
|
+
|
|
71
|
+
#### Example of emptiness
|
|
72
|
+
|
|
73
|
+
```yaml
|
|
74
|
+
hooks: [] # Empty hooks
|
|
75
|
+
connections: [] # Empty connections
|
|
76
|
+
tenant: {} # Effectively a no-op, emptiness does not apply to non-set resource config
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
---
|
|
80
|
+
|
|
81
|
+
[[table of contents]](../README.md#documentation)
|
|
@@ -0,0 +1,49 @@
|
|
|
1
|
+
# How to Contribute
|
|
2
|
+
|
|
3
|
+
While we may not prioritize some issues and feature requests, we are much more inclined to address them if accompanied with a code contribution. Please feel empowered to make a code contribution through a Github pull request. Please read the following for the best contributor experience.
|
|
4
|
+
|
|
5
|
+
## Getting started with development
|
|
6
|
+
|
|
7
|
+
The only requirement for development is having [node](https://nodejs.dev/) installed. Most modern versions will work but LTS is recommended.
|
|
8
|
+
|
|
9
|
+
Once node is installed, fork the Deploy CLI repository. Once code is downloaded to local development machine, run the following commands:
|
|
10
|
+
|
|
11
|
+
```shell
|
|
12
|
+
npm install # Installs all dependencies
|
|
13
|
+
npm run dev # Runs compiler, continuously observes source file changes
|
|
14
|
+
```
|
|
15
|
+
|
|
16
|
+
## Running tests
|
|
17
|
+
|
|
18
|
+
In order to run the entire test suite, execute `npm run test`.
|
|
19
|
+
|
|
20
|
+
To run a single test file or single test execute:
|
|
21
|
+
|
|
22
|
+
```shell
|
|
23
|
+
npx ts-mocha --timeout=5000 -p tsconfig.json <PATH_TO_TEST_FILE> -g=<OPTIONAL_NAME_OF_TEST>
|
|
24
|
+
```
|
|
25
|
+
|
|
26
|
+
### Examples
|
|
27
|
+
|
|
28
|
+
```shell
|
|
29
|
+
# Runs all tests within a file
|
|
30
|
+
npx ts-mocha --timeout=5000 -p tsconfig.json test/tools/auth0/handlers/actions.tests.js
|
|
31
|
+
|
|
32
|
+
# Runs a single test within a file
|
|
33
|
+
npx ts-mocha --timeout=5000 -p tsconfig.json \
|
|
34
|
+
test/tools/auth0/handlers/actions.tests.js \
|
|
35
|
+
-g="should create action"
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
## Code Contribution Checklist
|
|
39
|
+
|
|
40
|
+
Before finally submitting a PR, please ensure to complete the following:
|
|
41
|
+
|
|
42
|
+
- [ ] All code written in Typescript and compiles
|
|
43
|
+
- [ ] Accompanying tests for functional changes
|
|
44
|
+
- [ ] Any necessary documentation changes to pages in the /docs directory
|
|
45
|
+
- [ ] PR includes thorough description about what code does and why it was added
|
|
46
|
+
|
|
47
|
+
---
|
|
48
|
+
|
|
49
|
+
[[table of contents]](../README.md#documentation)
|
|
@@ -0,0 +1,45 @@
|
|
|
1
|
+
# Keyword Replacement
|
|
2
|
+
|
|
3
|
+
The Deploy CLI supports dynamic keyword replacement with environment-specific values. This enables a scalable multi-tenant workflow where all tenants share the same resource configuration files but inject subtly different values.
|
|
4
|
+
|
|
5
|
+
To use the keyword replacement, the `AUTH0_KEYWORD_REPLACEMENT_MAPPINGS` configuration property needs to contain the appropriate mappings. Then, in the resource configuration files, keywords can be injected through one of two ways:
|
|
6
|
+
|
|
7
|
+
- `@@EXAMPLE_KEY@@`: Using the `@` symbols causes the tool to perform a `JSON.stringify` on your value before replacing it. So if your value is a string, the tool will add quotes; if your value is an array or object, the tool will add braces.
|
|
8
|
+
- `##EXAMPLE_KEY##`: Using the `#` symbol causes the tool to perform a literal replacement; it will not add quotes or braces.
|
|
9
|
+
|
|
10
|
+
### Example `config.json`
|
|
11
|
+
|
|
12
|
+
```json
|
|
13
|
+
{
|
|
14
|
+
"AUTH0_DOMAIN": "test-tenant.us.auth0.com",
|
|
15
|
+
"AUTH0_CLIENT_ID": "FOO",
|
|
16
|
+
"AUTH0_CLIENT_SECRET": "BAR",
|
|
17
|
+
"AUTH0_KEYWORD_REPLACE_MAPPINGS": {
|
|
18
|
+
"ENVIRONMENT": "dev",
|
|
19
|
+
"ALLOWED_LOGOUTS": ["https://dev-test-site.com/logout", "localhost:3000/logout"],
|
|
20
|
+
"ALLOWED_ORIGINS": ["https://dev-test-site.com", "localhost:3000"]
|
|
21
|
+
}
|
|
22
|
+
}
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
### Example `tenant.yaml`
|
|
26
|
+
|
|
27
|
+
```yaml
|
|
28
|
+
tenant:
|
|
29
|
+
friendly_name: My ##ENVIRONMENT## tenant
|
|
30
|
+
allowed_logout_urls: @@ALLOWED_LOGOUTS@@
|
|
31
|
+
enabled_locales:
|
|
32
|
+
- en
|
|
33
|
+
clients:
|
|
34
|
+
- name: Test App
|
|
35
|
+
allowed_origins: @@ALLOWED_ORIGINS@@
|
|
36
|
+
allowed_logout_urls: @@ALLOWED_LOGOUTS@@
|
|
37
|
+
```
|
|
38
|
+
|
|
39
|
+
## Uni-directional Limitation
|
|
40
|
+
|
|
41
|
+
Currently, the Deploy CLI only preserves keywords during import. Once added, keywords are overwritten with subsequent exports. For this reason, it is recommended that if a workflow heavily depends on keyword replacement, to only perform imports in perpetuity. This limitation is noted in [this Github issue](https://github.com/auth0/auth0-deploy-cli/issues/328).
|
|
42
|
+
|
|
43
|
+
---
|
|
44
|
+
|
|
45
|
+
[[table of contents]](../README.md#documentation)
|
|
@@ -0,0 +1,98 @@
|
|
|
1
|
+
# Incorporating Into Multi-environment Workflows
|
|
2
|
+
|
|
3
|
+
The Deploy CLI supports working within a multi-tenant, multi-environment context. When integrated into your CI/CD development workflows, can be used to propagate Auth0 changes from feature development all the way through production.
|
|
4
|
+
|
|
5
|
+
In general, the advised workflow is as follows:
|
|
6
|
+
|
|
7
|
+
- Create a separate Auth0 tenant for each environment (ex: dev, staging, prod)
|
|
8
|
+
- Create a single repository of resource configuration files for all environments
|
|
9
|
+
- Add a step in your CI/CD pipeline when deploying to environments that applies the Auth0 resource configurations to the appropriate Auth0 tenant
|
|
10
|
+
|
|
11
|
+
## Tenant to Environment
|
|
12
|
+
|
|
13
|
+
It is recommended to have a separate Auth0 tenant/account for each environment you have. For example:
|
|
14
|
+
|
|
15
|
+
| Environment | Tenant |
|
|
16
|
+
| ----------- | ------------- |
|
|
17
|
+
| Development | travel0-dev |
|
|
18
|
+
| Testing | travel0-uat |
|
|
19
|
+
| Staging | travel0-stage |
|
|
20
|
+
| Production | travel0-prod |
|
|
21
|
+
|
|
22
|
+
## Resource configuration repository
|
|
23
|
+
|
|
24
|
+
When exported, your Auth0 tenant state will be represented as a set of resource configuration files, either in a [YAML or JSON format](./available-resource-config-formats.md). In a multi-environment context it is expected to have a single repository of resource configurations that is applied to all environments. In practice, this may exist as a directory in your project’s codebase or in a separate codebase altogether.
|
|
25
|
+
|
|
26
|
+
You should have at least one branch for each tenant in your repository, which allows you to make changes without deploying them (the changes would only deploy when you merged your branch into the master, or primary, branch). With this setup, you can have a continuous integration task for each environment that automatically deploys changes to the targeted environment whenever the master branch receives updates.
|
|
27
|
+
|
|
28
|
+
Your workflow could potentially look something like this:
|
|
29
|
+
|
|
30
|
+
1. Make changes to development.
|
|
31
|
+
2. Merge changes to testing (or `uat`).
|
|
32
|
+
3. Test changes to `uat`. When ready, move and merge the changes to `staging`.
|
|
33
|
+
4. Test `staging`. When ready, move and merge the changes to `production`.
|
|
34
|
+
|
|
35
|
+
You may want to set your production environment to deploy only when triggered manually.
|
|
36
|
+
|
|
37
|
+
## Uni-directional Flow
|
|
38
|
+
|
|
39
|
+
The multi-environment workflow works best when changes are propagated “up” in a single direction. Changes to the resource configuration files should first be applied to the lowest level environment (ex: dev) and then incrementally applied up through all other environments until applied to production. This uni-directional practice ensures sufficient testing and approval for changes to your tenant. Once set, it is recommended to not apply configurations directly to production through other means such as the Auth0 Dashboard or Management API unless those changes are captured by a subsequent Deploy CLI export. Otherwise, those changes are subject to overwrite.
|
|
40
|
+
|
|
41
|
+
## Environment-specific values
|
|
42
|
+
|
|
43
|
+
While it is expected that all environments will share the same set of resource configuration files, environment-specific values can be expressed through separate tool configuration files and dynamic [keyword replacement](keyword-replacement.md).
|
|
44
|
+
|
|
45
|
+
### Separate Config Files
|
|
46
|
+
|
|
47
|
+
Specifying a separate tool configuration file per environment can be used to keep the resource configuration files agnostic of environment but still cater for the needs of each environment. At a minimum, you will need to provide separate credentials for each environment, but it is also possible to exclude certain resources, enable deletion and perform dynamic keyword replacement on a per-environment basis.
|
|
48
|
+
|
|
49
|
+
### Example file structure
|
|
50
|
+
|
|
51
|
+
```
|
|
52
|
+
project-root
|
|
53
|
+
│
|
|
54
|
+
└───auth0
|
|
55
|
+
│ │ config-dev.json # Dev env config file
|
|
56
|
+
│ │ config-test.json # Test env config file
|
|
57
|
+
│ │ config-prod.json # Prod env config file
|
|
58
|
+
│ │ ... all other resource configuration files
|
|
59
|
+
│
|
|
60
|
+
└───src
|
|
61
|
+
│ ... your project code
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
### Dynamic Values via Keyword Replacement
|
|
65
|
+
|
|
66
|
+
Once separate configurations files are adopted for each environment, keyword replacement via the `AUTH0_KEYWORD_REPLACE_MAPPINGS` configuration property can be used to express the dynamic replacement values depending on the environment. For example, you may find it necessary to have a separate set of allowed origins for your clients (see below). To learn more, see [Keyword Replacement](keyword-replacement.md).
|
|
67
|
+
|
|
68
|
+
#### Example `config-dev.json`
|
|
69
|
+
|
|
70
|
+
```json
|
|
71
|
+
{
|
|
72
|
+
"AUTH0_DOMAIN": "travel0-dev.us.auth0.com",
|
|
73
|
+
"AUTH0_CLIENT_ID": "PdwQpGy62sHcsV6ufZNEVrV4GDlDhm74",
|
|
74
|
+
"AUTH0_ALLOW_DELETE": true,
|
|
75
|
+
"AUTH0_KEYWORD_REPLACE_MAPPINGS": {
|
|
76
|
+
"ENV": "dev",
|
|
77
|
+
"ALLOWED_ORIGINS": ["http://localhost:3000", "http://dev.travel0.com"]
|
|
78
|
+
}
|
|
79
|
+
}
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
#### Example `config-prod.json`
|
|
83
|
+
|
|
84
|
+
```json
|
|
85
|
+
{
|
|
86
|
+
"AUTH0_DOMAIN": "travel0.us.auth0.com",
|
|
87
|
+
"AUTH0_CLIENT_ID": "vZCEFsDYzXc1x9IomB8dF185e4cdVah5",
|
|
88
|
+
"AUTH0_ALLOW_DELETE": false,
|
|
89
|
+
"AUTH0_KEYWORD_REPLACE_MAPPINGS": {
|
|
90
|
+
"ENV": "prod",
|
|
91
|
+
"ALLOWED_ORIGINS": ["http://travel0.com"]
|
|
92
|
+
}
|
|
93
|
+
}
|
|
94
|
+
```
|
|
95
|
+
|
|
96
|
+
---
|
|
97
|
+
|
|
98
|
+
[[table of contents]](../README.md#documentation)
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
# Auth0 Terraform Provider
|
|
2
|
+
|
|
3
|
+
The Deploy CLI is not the only tool available for managing your Auth0 tenant configuration, there is also an [officially supported Terraform Provider](https://github.com/auth0/terraform-provider-auth0). [Terraform](https://terraform.io/) is a third-party tool for representing your cloud resources’s configurations as code. It has an established plug-in framework that supports a wide array of cloud providers, including Auth0.
|
|
4
|
+
|
|
5
|
+
Both the Deploy CLI and Terraform Provider exist to help you manage your Auth0 tenant configurations, but each has their own set of pros and cons.
|
|
6
|
+
|
|
7
|
+
You may want to consider the Auth0 Terraform Provider if:
|
|
8
|
+
|
|
9
|
+
- Your development workflows already leverages Terraform
|
|
10
|
+
- Your tenant management needs are granular or only pertain to a few specific resources
|
|
11
|
+
|
|
12
|
+
You may **not** want to consider the Auth0 Terraform Provider if:
|
|
13
|
+
|
|
14
|
+
- Your development workflow does not use Terraform, requiring extra setup upfront
|
|
15
|
+
- Your development workflows are primarily concerned with managing your tenants in bulk
|
|
16
|
+
- Your tenant has lots of existing resources, may require significant effort to “import”
|
|
17
|
+
|
|
18
|
+
---
|
|
19
|
+
|
|
20
|
+
[[table of contents]](../README.md#documentation)
|
|
@@ -0,0 +1,89 @@
|
|
|
1
|
+
# Using as a CLI
|
|
2
|
+
|
|
3
|
+
The Deploy CLI can be used as a standalone command line utility. Doing so provides a simple way to manage your Auth0 tenant configuration in CI/CD workflows.
|
|
4
|
+
|
|
5
|
+
## `export` command
|
|
6
|
+
|
|
7
|
+
Fetching configurations from Auth0 tenant to the local machine.
|
|
8
|
+
|
|
9
|
+
### `--output_folder`, `-o`
|
|
10
|
+
|
|
11
|
+
Path. Specifies the target directory for configuration files to be written to.
|
|
12
|
+
|
|
13
|
+
### `--config_file`, `-c`
|
|
14
|
+
|
|
15
|
+
Path. Specifies the user-defined configuration file (`config.json`). Refer to the list of [all configurable properties](./configuring-the-deploy-cli.md).
|
|
16
|
+
|
|
17
|
+
### `--format`, `-f`
|
|
18
|
+
|
|
19
|
+
Options: yaml or directory. Determines the file format of the exported resource configuration files. See: [Available Resource Config Formats](available-resource-config-formats).
|
|
20
|
+
|
|
21
|
+
### `--export_ids`, `-e`
|
|
22
|
+
|
|
23
|
+
Boolean. When enabled, will export the identifier fields for each resource. Default: `false`.
|
|
24
|
+
|
|
25
|
+
### `--env`
|
|
26
|
+
|
|
27
|
+
Boolean. Indicates if the tool should ingest environment variables or not. Default: `true`.
|
|
28
|
+
|
|
29
|
+
### `--debug`
|
|
30
|
+
|
|
31
|
+
Boolean. Enables more verbose error logging; useful during troubleshooting. Default: `false`.
|
|
32
|
+
|
|
33
|
+
### `--proxy_url`, `-p`
|
|
34
|
+
|
|
35
|
+
A url for proxying requests. Only set this if you are behind a proxy.
|
|
36
|
+
|
|
37
|
+
### Examples
|
|
38
|
+
|
|
39
|
+
```shell
|
|
40
|
+
# Fetching Auth0 tenant configuration in the YAML format
|
|
41
|
+
a0deploy export -c=config.json --format=yaml --output_folder=local
|
|
42
|
+
|
|
43
|
+
# Fetching Auth0 tenant configuration in directory (JSON) format
|
|
44
|
+
a0deploy export -c=config.json --format=directory --output_folder=local
|
|
45
|
+
|
|
46
|
+
# Fetching Auth0 tenant configurations with IDs of all assets
|
|
47
|
+
a0deploy export -c=config.json --format=yaml --output_folder=local --export_ids=true
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
## `import` command
|
|
51
|
+
|
|
52
|
+
Applying configurations from local machine to Auth0 tenant.
|
|
53
|
+
|
|
54
|
+
### `--input_file`, `-i`
|
|
55
|
+
|
|
56
|
+
Path. Specifies the location of the resource configuration files. For YAML formats, this will point to the `tenant.yaml` file, for directory formats, this will point to the resource configuration directory.
|
|
57
|
+
|
|
58
|
+
### `--config_file`, `-c`
|
|
59
|
+
|
|
60
|
+
Path. Specifies the user-defined configuration file (config.json). Refer to the list of [all configurable properties](./configuring-the-deploy-cli.md).
|
|
61
|
+
|
|
62
|
+
### `--env`
|
|
63
|
+
|
|
64
|
+
Boolean. Indicates if the tool should ingest environment variables or not. Default: `true`.
|
|
65
|
+
|
|
66
|
+
### `--proxy_url`, `-p`
|
|
67
|
+
|
|
68
|
+
A url for proxying requests. Only set this if you are behind a proxy.
|
|
69
|
+
|
|
70
|
+
### `--debug`
|
|
71
|
+
|
|
72
|
+
Boolean. Enables more verbose error logging; useful during troubleshooting. Default: `false`.
|
|
73
|
+
|
|
74
|
+
### Examples
|
|
75
|
+
|
|
76
|
+
```shell
|
|
77
|
+
# Deploying configuration for YAML formats
|
|
78
|
+
a0deploy import -c=config.json --input_file=local/tenant.yaml
|
|
79
|
+
|
|
80
|
+
# Deploying configuration for directory format
|
|
81
|
+
a0deploy import -c=config.json --input_file=local
|
|
82
|
+
|
|
83
|
+
# Deploying configuration with environment variables ignored
|
|
84
|
+
a0deploy import -c=config.json --input_file=local/tenant.yaml --env=false
|
|
85
|
+
```
|
|
86
|
+
|
|
87
|
+
---
|
|
88
|
+
|
|
89
|
+
[[table of contents]](../README.md#documentation)
|
|
@@ -0,0 +1,114 @@
|
|
|
1
|
+
# Using as a Node Module
|
|
2
|
+
|
|
3
|
+
The Deploy CLI can not only be used as a standalone CLI, but as a node module. Doing so allows you to manage Auth0 resources within expressive node scripts.
|
|
4
|
+
|
|
5
|
+
## `dump` function
|
|
6
|
+
|
|
7
|
+
Fetches configurations from Auth0 tenant to the local machine.
|
|
8
|
+
|
|
9
|
+
### Example
|
|
10
|
+
|
|
11
|
+
```ts
|
|
12
|
+
import { dump } from 'auth0-deploy-cli';
|
|
13
|
+
|
|
14
|
+
dump({
|
|
15
|
+
output_folder: './local',
|
|
16
|
+
format: 'yaml',
|
|
17
|
+
config: {
|
|
18
|
+
AUTH0_DOMAIN: '<YOUR_AUTH0_TENANT_DOMAIN>',
|
|
19
|
+
AUTH0_CLIENT_ID: '<YOUR_AUTH0_CLIENT_ID>',
|
|
20
|
+
AUTH0_CLIENT_SECRET: '<YOUR_AUTH0_CLIENT_SECRET>',
|
|
21
|
+
},
|
|
22
|
+
})
|
|
23
|
+
.then(() => {
|
|
24
|
+
console.log('Auth0 configuration export successful');
|
|
25
|
+
})
|
|
26
|
+
.catch((err) => {
|
|
27
|
+
console.log('Error during Auth0 configuration export:', err);
|
|
28
|
+
});
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
## Argument parameters
|
|
32
|
+
|
|
33
|
+
#### `format`
|
|
34
|
+
|
|
35
|
+
Options: `yaml` or `directory`. Determines the file format of the exported resource configuration files. See: [Available Resource Configuration Formats](available-resource-config-formats).
|
|
36
|
+
|
|
37
|
+
#### `output_folder`
|
|
38
|
+
|
|
39
|
+
Path. Specifies the target directory for configuration files to be written to.
|
|
40
|
+
|
|
41
|
+
#### `config`
|
|
42
|
+
|
|
43
|
+
Object. Configures behavior of utility. Refer to the list of [all configurable properties](./configuring-the-deploy-cli.md).
|
|
44
|
+
|
|
45
|
+
#### `config_file`
|
|
46
|
+
|
|
47
|
+
Path. Specifies the user-defined configuration file (config.json). Refer to the list of [all configurable properties](./configuring-the-deploy-cli.md).
|
|
48
|
+
|
|
49
|
+
#### `export_ids`
|
|
50
|
+
|
|
51
|
+
Boolean: When enabled, will export the identifier fields for each resource. Default: false.
|
|
52
|
+
|
|
53
|
+
#### `env`
|
|
54
|
+
|
|
55
|
+
Boolean. Indicates if the tool should ingest environment variables or not. Default: `false`.
|
|
56
|
+
|
|
57
|
+
#### `proxy_url`
|
|
58
|
+
|
|
59
|
+
A url for proxying requests. Only set this if you are behind a proxy.
|
|
60
|
+
|
|
61
|
+
## `deploy` function
|
|
62
|
+
|
|
63
|
+
Applies configurations from local machine to Auth0 tenant.
|
|
64
|
+
|
|
65
|
+
### Argument parameters
|
|
66
|
+
|
|
67
|
+
#### `input_file`
|
|
68
|
+
|
|
69
|
+
Path. Specifies the location of the resource configuration files. For YAML formats, this will point to the tenant.yaml file. For directory formats, this will point to the resource configuration directory.
|
|
70
|
+
|
|
71
|
+
#### `config`
|
|
72
|
+
|
|
73
|
+
Object. Configures behavior of utility. Refer to the list of [all configurable properties](./configuring-the-deploy-cli.md).
|
|
74
|
+
|
|
75
|
+
#### `config_file`
|
|
76
|
+
|
|
77
|
+
Path. Specifies the user-defined configuration file (config.json). Refer to the list of [all configurable properties](./configuring-the-deploy-cli.md).
|
|
78
|
+
|
|
79
|
+
#### `export_ids`
|
|
80
|
+
|
|
81
|
+
Boolean: When enabled, will export the identifier fields for each resource. Default: `false`.
|
|
82
|
+
|
|
83
|
+
#### `env`
|
|
84
|
+
|
|
85
|
+
Boolean. Indicates if the tool should ingest environment variables or not. Default: `false`.
|
|
86
|
+
|
|
87
|
+
#### `proxy_url`
|
|
88
|
+
|
|
89
|
+
A url for proxying requests. Only set this if you are behind a proxy.
|
|
90
|
+
|
|
91
|
+
### Example
|
|
92
|
+
|
|
93
|
+
```ts
|
|
94
|
+
import { deploy } from 'auth0-deploy-cli';
|
|
95
|
+
|
|
96
|
+
deploy({
|
|
97
|
+
input_file: './local/tenant.yaml',
|
|
98
|
+
config: {
|
|
99
|
+
AUTH0_DOMAIN: '<YOUR_AUTH0_TENANT_DOMAIN>',
|
|
100
|
+
AUTH0_CLIENT_ID: '<YOUR_AUTH0_CLIENT_ID>',
|
|
101
|
+
AUTH0_CLIENT_SECRET: '<YOUR_AUTH0_CLIENT_SECRET>',
|
|
102
|
+
},
|
|
103
|
+
})
|
|
104
|
+
.then(() => {
|
|
105
|
+
console.log('Auth0 configuration applied to tenant successful');
|
|
106
|
+
})
|
|
107
|
+
.catch((err) => {
|
|
108
|
+
console.log('Error when applying configuration to Auth0 tenant:', err);
|
|
109
|
+
});
|
|
110
|
+
```
|
|
111
|
+
|
|
112
|
+
---
|
|
113
|
+
|
|
114
|
+
[[table of contents]](../README.md#documentation)
|
package/lib/commands/import.d.ts
CHANGED
package/lib/commands/import.js
CHANGED
|
@@ -12,6 +12,7 @@ var __importDefault = (this && this.__importDefault) || function (mod) {
|
|
|
12
12
|
return (mod && mod.__esModule) ? mod : { "default": mod };
|
|
13
13
|
};
|
|
14
14
|
Object.defineProperty(exports, "__esModule", { value: true });
|
|
15
|
+
exports.findUnreplacedKeywords = void 0;
|
|
15
16
|
const nconf_1 = __importDefault(require("nconf"));
|
|
16
17
|
const configFactory_1 = require("../configFactory");
|
|
17
18
|
const tools_1 = require("../tools");
|
|
@@ -40,9 +41,43 @@ function importCMD(params) {
|
|
|
40
41
|
yield context.load();
|
|
41
42
|
const config = (0, configFactory_1.configFactory)();
|
|
42
43
|
config.setProvider((key) => nconf_1.default.get(key));
|
|
43
|
-
|
|
44
|
+
(0, exports.findUnreplacedKeywords)(context.assets);
|
|
44
45
|
yield (0, tools_1.deploy)(context.assets, context.mgmtClient, config);
|
|
45
46
|
logger_1.default.info('Import Successful');
|
|
46
47
|
});
|
|
47
48
|
}
|
|
48
49
|
exports.default = importCMD;
|
|
50
|
+
const findUnreplacedKeywords = (assets) => {
|
|
51
|
+
const recursiveFindUnreplacedKeywords = (target) => {
|
|
52
|
+
let unreplaced = [];
|
|
53
|
+
if (target === undefined || target === null)
|
|
54
|
+
return [];
|
|
55
|
+
if (Array.isArray(target)) {
|
|
56
|
+
target.forEach((child) => {
|
|
57
|
+
unreplaced.push(...recursiveFindUnreplacedKeywords(child));
|
|
58
|
+
});
|
|
59
|
+
}
|
|
60
|
+
else if (typeof target === 'object') {
|
|
61
|
+
Object.values(target).forEach((child) => {
|
|
62
|
+
unreplaced.push(...recursiveFindUnreplacedKeywords(child));
|
|
63
|
+
});
|
|
64
|
+
}
|
|
65
|
+
if (typeof target === 'string') {
|
|
66
|
+
const arrayMatches = target.match(/(?<=@@).*(?=@@)/g);
|
|
67
|
+
if (arrayMatches !== null) {
|
|
68
|
+
return arrayMatches;
|
|
69
|
+
}
|
|
70
|
+
const keywordMatches = target.match(/(?<=##).*(?=##)/g);
|
|
71
|
+
if (keywordMatches !== null) {
|
|
72
|
+
return keywordMatches;
|
|
73
|
+
}
|
|
74
|
+
}
|
|
75
|
+
return unreplaced;
|
|
76
|
+
};
|
|
77
|
+
const unreplacedKeywords = recursiveFindUnreplacedKeywords(assets);
|
|
78
|
+
if (unreplacedKeywords.length > 0) {
|
|
79
|
+
throw `Unreplaced keywords found: ${unreplacedKeywords.join(', ')}. Either correct these values or add to AUTH0_KEYWORD_REPLACE_MAPPINGS configuration.`;
|
|
80
|
+
}
|
|
81
|
+
return;
|
|
82
|
+
};
|
|
83
|
+
exports.findUnreplacedKeywords = findUnreplacedKeywords;
|
|
@@ -44,7 +44,7 @@ function dump(context) {
|
|
|
44
44
|
// Dump html to file
|
|
45
45
|
const htmlFile = path_1.default.join(pagesFolder, `${page.name}.html`);
|
|
46
46
|
logger_1.default.info(`Writing ${htmlFile}`);
|
|
47
|
-
fs_extra_1.default.writeFileSync(htmlFile, page.html);
|
|
47
|
+
fs_extra_1.default.writeFileSync(htmlFile, page.html || '');
|
|
48
48
|
return Object.assign(Object.assign({}, page), { html: `./pages/${page.name}.html` });
|
|
49
49
|
});
|
|
50
50
|
return { pages };
|
|
@@ -1,11 +1,22 @@
|
|
|
1
1
|
import DefaultHandler from './default';
|
|
2
|
-
import { Asset, Assets } from '../../../types';
|
|
2
|
+
import { Asset, Assets, Language } from '../../../types';
|
|
3
3
|
export declare const schema: {
|
|
4
4
|
type: string;
|
|
5
5
|
};
|
|
6
|
+
export declare type Tenant = Asset & {
|
|
7
|
+
enabled_locales: Language[];
|
|
8
|
+
flags: {
|
|
9
|
+
[key: string]: boolean;
|
|
10
|
+
};
|
|
11
|
+
};
|
|
6
12
|
export default class TenantHandler extends DefaultHandler {
|
|
13
|
+
existing: Tenant;
|
|
7
14
|
constructor(options: DefaultHandler);
|
|
8
15
|
getType(): Promise<Asset>;
|
|
9
16
|
validate(assets: Assets): Promise<void>;
|
|
10
17
|
processChanges(assets: Assets): Promise<void>;
|
|
11
18
|
}
|
|
19
|
+
export declare const sanitizeMigrationFlags: ({ existingFlags, proposedFlags, }: {
|
|
20
|
+
existingFlags: Tenant['flags'];
|
|
21
|
+
proposedFlags: Tenant['flags'];
|
|
22
|
+
}) => Tenant['flags'];
|
|
@@ -41,7 +41,7 @@ var __importDefault = (this && this.__importDefault) || function (mod) {
|
|
|
41
41
|
return (mod && mod.__esModule) ? mod : { "default": mod };
|
|
42
42
|
};
|
|
43
43
|
Object.defineProperty(exports, "__esModule", { value: true });
|
|
44
|
-
exports.schema = void 0;
|
|
44
|
+
exports.sanitizeMigrationFlags = exports.schema = void 0;
|
|
45
45
|
const validationError_1 = __importDefault(require("../../validationError"));
|
|
46
46
|
const default_1 = __importStar(require("./default"));
|
|
47
47
|
const pages_1 = require("./pages");
|
|
@@ -61,6 +61,7 @@ class TenantHandler extends default_1.default {
|
|
|
61
61
|
getType() {
|
|
62
62
|
return __awaiter(this, void 0, void 0, function* () {
|
|
63
63
|
const tenant = yield this.client.tenant.getSettings();
|
|
64
|
+
this.existing = tenant;
|
|
64
65
|
blockPageKeys.forEach((key) => {
|
|
65
66
|
if (tenant[key])
|
|
66
67
|
delete tenant[key];
|
|
@@ -84,10 +85,18 @@ class TenantHandler extends default_1.default {
|
|
|
84
85
|
processChanges(assets) {
|
|
85
86
|
return __awaiter(this, void 0, void 0, function* () {
|
|
86
87
|
const { tenant } = assets;
|
|
87
|
-
|
|
88
|
-
|
|
88
|
+
// Do nothing if not set
|
|
89
|
+
if (!tenant)
|
|
90
|
+
return;
|
|
91
|
+
const existingTenant = this.existing || (yield this.getType());
|
|
92
|
+
const updatedTenant = Object.assign(Object.assign({}, tenant), { flags: (0, exports.sanitizeMigrationFlags)({
|
|
93
|
+
existingFlags: existingTenant.flags,
|
|
94
|
+
proposedFlags: tenant.flags,
|
|
95
|
+
}) });
|
|
96
|
+
if (updatedTenant && Object.keys(updatedTenant).length > 0) {
|
|
97
|
+
yield this.client.tenant.updateSettings(updatedTenant);
|
|
89
98
|
this.updated += 1;
|
|
90
|
-
this.didUpdate(
|
|
99
|
+
this.didUpdate(updatedTenant);
|
|
91
100
|
}
|
|
92
101
|
});
|
|
93
102
|
}
|
|
@@ -96,3 +105,29 @@ __decorate([
|
|
|
96
105
|
(0, default_1.order)('100')
|
|
97
106
|
], TenantHandler.prototype, "processChanges", null);
|
|
98
107
|
exports.default = TenantHandler;
|
|
108
|
+
const sanitizeMigrationFlags = ({ existingFlags = {}, proposedFlags = {}, }) => {
|
|
109
|
+
/*
|
|
110
|
+
Tenants can only update migration flags that are already configured.
|
|
111
|
+
If moving configuration from one tenant to another, there may be instances
|
|
112
|
+
where different migration flags exist and cause an error on update. This
|
|
113
|
+
function removes any migration flags that aren't already present on the target
|
|
114
|
+
tenant. See: https://github.com/auth0/auth0-deploy-cli/issues/374
|
|
115
|
+
*/
|
|
116
|
+
const tenantMigrationFlags = [
|
|
117
|
+
'disable_clickjack_protection_headers',
|
|
118
|
+
'enable_mgmt_api_v1',
|
|
119
|
+
'trust_azure_adfs_email_verified_connection_property',
|
|
120
|
+
'include_email_in_reset_pwd_redirect',
|
|
121
|
+
'include_email_in_verify_email_redirect',
|
|
122
|
+
];
|
|
123
|
+
return Object.keys(proposedFlags).reduce((acc, proposedKey) => {
|
|
124
|
+
const isMigrationFlag = tenantMigrationFlags.includes(proposedKey);
|
|
125
|
+
if (!isMigrationFlag)
|
|
126
|
+
return Object.assign(Object.assign({}, acc), { [proposedKey]: proposedFlags[proposedKey] });
|
|
127
|
+
const keyCurrentlyExists = existingFlags[proposedKey] !== undefined;
|
|
128
|
+
if (keyCurrentlyExists)
|
|
129
|
+
return Object.assign(Object.assign({}, acc), { [proposedKey]: proposedFlags[proposedKey] });
|
|
130
|
+
return acc;
|
|
131
|
+
}, {});
|
|
132
|
+
};
|
|
133
|
+
exports.sanitizeMigrationFlags = sanitizeMigrationFlags;
|
package/lib/types.d.ts
CHANGED
|
@@ -1,4 +1,5 @@
|
|
|
1
1
|
import { PromptTypes, ScreenTypes, Prompts, PromptsCustomText, PromptSettings } from './tools/auth0/handlers/prompts';
|
|
2
|
+
import { Tenant } from './tools/auth0/handlers/tenant';
|
|
2
3
|
import { Theme } from './tools/auth0/handlers/themes';
|
|
3
4
|
declare type SharedPaginationParams = {
|
|
4
5
|
checkpoint?: boolean;
|
|
@@ -173,10 +174,8 @@ export declare type BaseAuth0APIClient = {
|
|
|
173
174
|
getAll: () => Promise<Asset[]>;
|
|
174
175
|
};
|
|
175
176
|
tenant: APIClientBaseFunctions & {
|
|
176
|
-
getSettings: () => Promise<
|
|
177
|
-
|
|
178
|
-
}>;
|
|
179
|
-
updateSettings: (arg0: Asset) => Promise<void>;
|
|
177
|
+
getSettings: () => Promise<Tenant>;
|
|
178
|
+
updateSettings: (arg0: Partial<Tenant>) => Promise<Tenant>;
|
|
180
179
|
};
|
|
181
180
|
triggers: APIClientBaseFunctions & {
|
|
182
181
|
getTriggerBindings: () => Promise<Asset>;
|
|
@@ -266,7 +265,7 @@ export declare type Assets = Partial<{
|
|
|
266
265
|
roles: Asset[] | null;
|
|
267
266
|
rules: Asset[] | null;
|
|
268
267
|
rulesConfigs: Asset[] | null;
|
|
269
|
-
tenant:
|
|
268
|
+
tenant: Tenant | null;
|
|
270
269
|
triggers: Asset[] | null;
|
|
271
270
|
exclude?: {
|
|
272
271
|
[key: string]: string[];
|
package/lib/utils.d.ts
CHANGED
|
@@ -91,7 +91,7 @@ export declare function stripIdentifiers(auth0: Auth0, assets: Assets): {
|
|
|
91
91
|
roles?: Asset[] | null | undefined;
|
|
92
92
|
rules?: Asset[] | null | undefined;
|
|
93
93
|
rulesConfigs?: Asset[] | null | undefined;
|
|
94
|
-
tenant?:
|
|
94
|
+
tenant?: import("./tools/auth0/handlers/tenant").Tenant | null | undefined;
|
|
95
95
|
triggers?: Asset[] | null | undefined;
|
|
96
96
|
exclude?: {
|
|
97
97
|
[key: string]: string[];
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "auth0-deploy-cli",
|
|
3
|
-
"version": "7.
|
|
3
|
+
"version": "7.14.0",
|
|
4
4
|
"description": "A command line tool for deploying updates to your Auth0 tenant",
|
|
5
5
|
"main": "lib/index.js",
|
|
6
6
|
"bin": {
|
|
@@ -52,7 +52,7 @@
|
|
|
52
52
|
"devDependencies": {
|
|
53
53
|
"@types/expect": "^24.3.0",
|
|
54
54
|
"@types/mocha": "^9.1.0",
|
|
55
|
-
"@typescript-eslint/parser": "^5.
|
|
55
|
+
"@typescript-eslint/parser": "^5.27.0",
|
|
56
56
|
"chai": "^4.3.6",
|
|
57
57
|
"chai-as-promised": "^7.1.1",
|
|
58
58
|
"cross-env": "^3.1.4",
|
|
@@ -69,7 +69,7 @@
|
|
|
69
69
|
"rimraf": "^3.0.2",
|
|
70
70
|
"rmdir-sync": "^1.0.1",
|
|
71
71
|
"ts-mocha": "^9.0.2",
|
|
72
|
-
"typescript": "^4.
|
|
72
|
+
"typescript": "^4.7.3"
|
|
73
73
|
},
|
|
74
74
|
"overrides": {
|
|
75
75
|
"istanbul-reports": "3.1.4"
|