Metadata API: prevent Delegation role names to be one of top level metadata roles
See original GitHub issueDescription of issue or feature request:
Current behavior:
Delegation role names are not restricted in any way in the spec, but they are targets metadata role names.
That could lead to a problem if delegation role names are one of root
, timestamp
, snapshot
or targets
.
Expected behavior: Make sure that delegation role names aren’t one of the top-level metadata roles.
Issue Analytics
- State:
- Created 2 years ago
- Comments:7 (4 by maintainers)
Top Results From Across the Web
Metadata API: Delegation role names validation #1527 - GitHub
validate that role names are not using top-level metadata names in Metadata API: Metadata API: prevent Delegation role names to be one of...
Read more >Profile | Metadata API Developer Guide
Represents a user profile. A profile defines a user's permission to perform different functions within Salesforce. This type extends the Metadata metadata type ......
Read more >Metadata API Developer Guide
Metadata is data that describes other data. To understand how Salesforce defines metadata, contrast business data with Salesforce metadata.
Read more >IAM basic and predefined roles reference - Google Cloud
This page lists all basic and predefined roles for Identity and Access Management (IAM). To learn more about IAM roles, see Roles and...
Read more >Policies | Vault - HashiCorp Developer
You can think of the policy's name as a pointer or symlink to its set of rules. Most importantly, the security team maps...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
same check does make sense in a client: we would not want to accidentally overwrite our local root.json because a targets decides to delegate to a “root” role version 9000.
I don’t think there are practical risks of that – the client would have to succeed in downloading and verifying the file as a targets metadata before it would be written to local disk but this still seems like a reasonable check for a client to make
the legacy client also prevents empty string as rolename – this seems like a reasonable take for ngclient too