Skip to main content
Release Notes

Use multiple wildcard in resource filters

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.

API Resource List

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.

info

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.