How are glob patterns (*, **) written; how is the path test tool used?

Short answer

A glob pattern starts with / (a pattern that contains **, e.g. **/login, can also be written without /) and describes the whole path (Glob Path). * matches any character sequence within a single segment and does not cross the / boundary; ** crosses segment boundaries (/files/** covers /files/a/b.png); ? matches a single character, [0-9] a character set, and {png,jpg} alternatives. The matching is case-sensitive and does not take the query string into account. When a value that contains a wildcard is written in the Path field of the Add or Edit form, the Input / Result test table appears below the field: a row is added with +, an example path is written in Input, and Result instantly shows the match with a green check or a red cross; the rows are not saved. The pattern is also written with waf fw-rules add in WEB-CLI; there is no test table there.

Problem: The Glob Pattern Does Not Catch the Expected Paths

A rule is to be written so that it covers several paths; exactly which requests the pattern catches should be seen without saving. Paths that do not match the pattern stay outside the rule and fall into another glob rule or into the Any Paths rule.

Solution: Two Methods

Your situation	Suitable method
Writing the pattern and trying it with example paths	Method 1: Path field and test table
Script or command line	Method 2: WEB-CLI

Pattern examples (tried with the matcher that the test table uses):

Pattern	Matches	Does not match
/api/v*/login	/api/v1/login, /api/v2/login	/api/v1/auth/login, /API/v1/login
/api/*	/api/x	/api/v1/login, /api
/files/**	/files/a, /files/a/b.png	/filesx/a, /files (the test table shows it as matched, it does not match at runtime)
/img/*.{png,jpg}	/img/a.png, /img/a.jpg	/img/a.gif, /img/x/a.png
/user/[0-9]*	/user/1, /user/123	/user/a1
/a?c	/abc	/ac, /abbc
/static/**/*.js	/static/a.js, /static/x/y/a.js	/static/a.css

Method 1: Path Field and Test Table Recommended

• How it works The pattern is written in the Path field of the rule form; the test table shows whether example paths match the pattern or not without saving.
• Where it is opened Left Monitor Panel → WAF-Protected vServices → vService → WAF Management → the mode card of the host group → N page types → Add or Edit
• Requirement WAF protection enabled on the vService
• vService type HTTP vService with WAF protection enabled

Step-by-Step Configuration

1

Adım 1 Open the Page Types tab

In the Left Monitor Panel, the vService is clicked on the WAF-Protected vServices tab, the WAF Management tab is opened and the N page types row under the mode card of the relevant host group is clicked (accessing the screen).

2

Adım 2 Open the form

For a new rule, Add on the toolbar is clicked; to change the pattern of an existing rule, the row is selected and Edit is clicked.

3

Adım 3 Write the pattern

The pattern is written in the Path field. When a wildcard is detected, the globe icon on the right of the field becomes active, the test table appears below the field, and if Structure Checks is on, the Path Length and Path Depth fields are added to the form (add screen (glob)). The info icon opens the page that explains the glob syntax in a new tab.

4

Adım 4 Add a test row

A new row is added with the + icon in the Result header of the table (the table opens with one empty row).

5

Adım 5 Try the example paths

An example request path without the query string is written in the Input field; the Result cell shows a green check for a path that matches the pattern and a red cross for a path that does not. The paths that should be covered and the paths that should stay outside are tried in separate rows; an unnecessary row is deleted with the trash icon. The table rows are not saved with the form; the table starts empty at every opening.

6

Adım 6 Save

After the other fields are filled in, Add (new rule) or Edit (existing rule) at the bottom of the form is clicked; the rule is applied without a separate deployment step. In a cluster setup, with the default auto-sync, the change is also sent to the peer device automatically; if Manual Sync Mode is on, it is sent manually with Synchronize.

Verification

1Test tableTR7 side

The Result cells of the example paths that should be covered and that should stay outside are examined.

ExpectedA green check for the ones to be covered, a red cross for the ones to stay outside

2Event LogsTR7 side

A request that violates the rule is sent to a path that matches the pattern; the Matching Path Rules row on the Request & Location tab of the Event Logs record is examined.

ExpectedThe pattern of the glob rule

A record is produced only while the host group is in Monitor or Blocking mode, when the score of the request reaches the blocking threshold or when a signature in the Monitor state is triggered.

Method 2: WEB-CLI

• How it works The pattern is written in the --path.input field of the waf fw-rules add command; a value that contains a wildcard becomes a glob rule on its own. There is no test table; the pattern can be tried beforehand with the table in the interface.
• Where it is opened WEB-CLI → waf fw-rules add · waf fw-rules list
• Requirement WEB-CLI access; the ID of the host group (with waf host-groups list poolId <vService>)
• vService type HTTP vService with WAF protection enabled

Step-by-Step Configuration

1

Adım 1 Add the glob rule

A value that contains a wildcard is written in single quotes (request path):

waf fw-rules add poolId <vService> hostGroupId <group> --path.input '/api/v*/login'

The command gives no output when it succeeds.

2

Adım 2 See the rule in the list

waf fw-rules list poolId <vService> hostGroupId <group>

Verification

1ListTR7 side

The rule list is fetched again, or the Page types list in the interface is examined.

ExpectedThe /api/v*/login row (with the highlight color in the interface)

Common Mistakes

• Expecting multiple segments with *. * is a single segment; /api/* does not match /api/v1/login, while /api/** does.
• Assuming that the root path is included in the pattern. /api/* does not match /api; /api/** does not match /api at runtime either, while the test table shows it as matched in this case. For the root itself (/api), a separate exact rule is added.
• Overlooking the uppercase/lowercase difference. /API/v1/login does not match /api/v*/login.
• Including the query string in the pattern. The matching is done only on the path; ? is the single-character wildcard in the pattern.

How it is done in the documentation

• Add · Glob Path
• Add · The Path Test Table
• Add · The Add Screen - Glob Path
• WEB-CLI waf fw-rules · The Request Path

Related questions

• What is the difference between an Exact Path and a glob path?
• How do I merge several page types into one rule (Merge)?
• What are Dynamic Paths, Excluded Paths and Dynamic Path Exclusions for?