Starting today multiple wildcard support is globally available. Requests to check authorization can include multiple ✶ anywhere in the resourceUri. Requests to the authorization check endpoint accept resourceUris for example:
- In multiple places in the hierarchy:
/resources/✶/nested-resource/✶ - Present in requests for namespaces:
namespace:✶/resources/lower-namespace:✶/nested-resource
API update: Resource List
To further support this functionality the List user resources endpoint now accepts a new parameter Collection Configuration that explicitly enables the type of collection result a request expects.
The original functionality was to only return immediate top level resource matches to a request. This functionality remains the default. When searching for /resources/✶, the result will be a list of matching resources: [ 'resources/001', 'resources/002', ... ].
The endpoint now supports INCLUDE_NESTED.
Specifying this value cases deeply nested resources to also be returned. A request for /resources/✶, will return: [ 'resources/001', 'resources/002/sub-resource/✶', 'resources/003/sub-resource/003' ]. And additionally requests can include multiple wildcards: /resources/✶/sub-resources/✶, will filter by both resources and sub-resources.
What's great about this new functionality is that users with access to ✶ will also successfully return results. Having access to all resources templates the result. ✶, with a search for /resources/✶ will return [ '/resources/✶' ], making it easier to utilize these results without adding extra filtering logic.