auth0-deploy-cli
auth0-deploy-cli copied to clipboard
Change client grants filenames with directory structure
Describe the problem you'd like to have solved
I'm exporting Auth0 Configurations with the directory structure and have multiple tenant with the same codebase. Inside the "grants" directory the file name contains information about the audience which is related to the tenant making it hard to use a VCS with multi tenants.
Describe the ideal solution
I think having a single file (grants.json) with an array of grants can solve this issue because you can then make use of the "keyword replace mapping" functionality to handle tenant-related values.
Alternatives and current work-arounds
No idea. Using yaml export can solves this issue but makes it really hard to handle exports because #328
This is an interesting problem to solve. You're correct about tenant-specific data existing in the exported configuration files. Given a multi-tenant dealing with hypothetical tenants A and B, do you think it would be appropriate to dynamically swap out the audience value's domain from tenant A with tenant B's domain? My hunch is that it would work in most cases but perhaps not all; might be a bit too clever.
I think this is something that should be natively handled by the tool and not addressed with the keyword replace mappings.
I'd like to noodle on this one a bit more, admittedly I need to familiarize myself with some of the edge cases that might present in this situation. Please let me know if you've had any additional thoughts on this.
Correct me if I'm wrong. What you are suggesting is to replace the value of the audience field with the "friendly name", the same way the client_id is now the client name. This way you can use the same audience name in every tenant.
Consider the following exported configuration:
clientGrants:
- client_id: Deploy CLI Application
audience: https://test-app.us.auth0.com/api/v2/
scope:
- read:client_grants
- create:client_grants
- delete:client_grants
- update:client_grants
The audience here is hardcoded with the tenant domain. When you attempt to apply this configuration to another tenant, it will fail with the error: Not Found: No resource with identifier https://test-app.us.auth0.com/api/v2/. What I'm suggesting is dynamically detect replace these audiences with the target domains.
Related, I stumbled upon a guide in the official docs on how to navigate this specific situation. Like you guessed, it recommends leveraging the keyword replacement, which is fine, but I'm optimistic that there's some sort of smarter mechanism for this.
I just want to point I was mainly struggling with the directory export not the yaml in particular with the file name generated in the grants directory.
Following your last example, with the directory structure you end up having a grants/Deploy CLI Application (https---test-app.us.auth0.com-api-v2-).json file.
To workaround this issue I made a fork and changed the parse and dump methods to expect a single grants/grants.json file. Now I can easily take advantage of the keyword replacement and have something like this:
[
{
"client_id": "Deploy CLI Application",
"audience": "https://##AUTH0_DOMAIN##/api/v2/",
"scope": [
"read:client_grants",
"create:client_grants",
"delete:client_grants",
"update:client_grants"
]
}
]
As you stated previously I'm not sure this is the best solution but for my use case it works.
@ebusi Ah! Ok I see what you mean now. I agree the filename is problematic and don't see any reason why we couldn't exclude the audience value. For the above example, if the generated client grant file name was grants/Deploy CLI Application.json instead, that would satisfy the original complaint, correct?
Yup. That should work.
@ebusi We actually introduced a "fix" for this but didn't account for the cases where a single client would have multiple associated grants. We've introduced a more holistic fix in 7.16.1 that produces unique and tenant-agnostic filenames for client grants. I'd really appreciate it if you gave it a shot!
Going to close this one out. If anyone has any additional feedback please feel empowered to create a new Github issue!