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:
- Present in requests for namespaces:
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
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.