Glob Syntax

The Glob syntax is used by the Filesystem, HTTP, and Child Process policies, as well as the incoming route path string. It's a common Unix shell syntax for specifying patterns, similar in purpose yet simpler than Regular Expressions.

Here is a quick overview of the capabilities of the Glob syntax.

  • An * character will match any character, either 0 or many occurrences
  • Using ** will match zero or more directories and subdirectories
  • A ? character will match a single character
  • Using [abc] will match one character from within the bracket
  • Using [a-z] or [0-9] will match a character from the range

The / path separator will not be matched using the above patterns. This makes the Glob syntax particularly useful when working with URLs or files.

Note: Unlike the glob functionality built into your shell, the glob matcher used with Intrinsic policies will match “hidden” files (those which begin with a .) when using **. This means the pattern * will match foo as well as .foo.

Glob Examples

Exact: /var/x.txt

This example does not contain any of the wildcard symbols mentioned above and so will only match exactly the filename /var/x.txt. It will not, for example, match a file containing that string, such as /tmp/var/x.txt.

Single Asterisk: /tmp/*.jpg

This example can be read as “any JPG file immediately inside of /tmp”. It will match filenames such as /tmp/photo.jpg and /tmp/another-photo.jpg. It will not match /tmp/anim.gif because the file extension is incorrect. It also won't match /tmp/photos/photo.jpg as this is a within sub-directory (specifically, the * does not match forward slashes). For sub-directory matching we need to use **.

Double Asterisk: /tmp/**/*.jpg

This example can be read of as “match any JPG file within any subdirectory within /tmp, even /tmp/ itself”. It will still match our previous example of /tmp/photo.jpg. It will even match /tmp/photos/photo.jpg which is nested deeper.

Policy Specificity

As seen above in the examples, the glob syntax lets you write policies at various levels of specificity. For example, you may want to allow a particular file to be read by the fs module:

policy.fs.allowRead(`${__dirname}/config.txt`);

On the other hand, you may want to allow all JSON files in a particular directory (but no deeper) to be read:

policy.fs.allowRead(`${__dirname}/dictionaries/*.json`);

Take care with wildcard policies, as you may be granting your application more privileges than it needs.