Overview
The glob-match string you enter for Target in a scope ruleset is matched against the glob_path property of the request object.
Example glob_path:
Acme Integration/My_DB/foo_schema/bar_table
The path root ("Acme Integration"), is the name you entered when setting up the integration (the alias).
The remainder of the path are sub-resource names separated by "/". The sub resources and their names, are as mapped during scans.
Comprehensive examples
See this comprehensive reference table ↗ for integration types' path structures, and glob matching examples.
Best practices
Use only the "*", "?", and "**" wildcards to keep things simple and manageable.
Other glob matching expressions can be used but are currently considered experimental, and you must trial and error these expressions. Our glob matching implementation follows the "Pattern Matching Notation" of POSIX standard IEEE Std 1003.1 (sample documentation ↗).
Target path matching basics
The "/" path separators are strictly respected: "My Integration/*/foo*" will match any second subresource that starts with "foo" but not a first-level sub-resource, or a third level sub-resource.
The "**" expression ("globster") is supported and is very useful. It allows selecting things at any depth, but note that "/" path separators are still strictly respected:
"My Integration/**/foo*" will match any resource that is at level 3 and onwards ("My integration" is level 1).
"My Integration**" will match any resource in any integration that starts with "My Integration".
"My Integration/**-dev" will match any resource that belongs to My Integration and ends with "-dev" (at any level)/
Literal “/” in resource names need to be escaped using “\”.