AEM Dispatcher Filter Tester

What this tool does

The tester reads your AEM Dispatcher filter rules and shows, for each URL you give it, whether Dispatcher would allow or deny it and which rule decided. Paste cache rules too and it shows whether the response would be cached. A built-in security check runs the requests attackers try first, and the rule checks point out patterns that let more through than intended.

It works with AEM as a Cloud Service (filters.any, rules.any) and AEM 6.5 (dispatcher.any or farm files), and runs entirely in your browser.

When to use it

• Before deploying a filter change, to see which URLs it opens or closes.
• When a page returns 404 only through Dispatcher, to find the rule that blocks it.
• In a security review, to confirm that console, QueryBuilder, JSON dumps and the Sling POST servlet are blocked.
• When pages aren’t cached, to see whether it’s the rules, the query string or the request.

How to use it

1. Paste your filter rules on the left. A whole farm file works too: the tester finds the /filter section, the cache rules and /ignoreUrlParams in it.
2. List the URLs to test on the right, one per line. Write them as they reach Dispatcher, after Apache rewrites (/content/mysite/en.html, not /en.html). Put a method first to test it: POST /content/mysite/en/contact.form.html.
3. Optionally open Cache rules and ignored URL parameters and paste rules.any and your /ignoreUrlParams rules.
4. Read the results. Open How Dispatcher reads it on any row to see the path, selectors, extension, suffix and query, and every rule that matched.
5. Check the Security check tab with your content root, and the Rule checks tab.

How Dispatcher matches

• Last match wins. Every rule is checked in the order it appears; the last matching rule decides. Numbering doesn’t change the order.
• No match means deny. A request no rule matches gets a 404.
• Every property must match. A rule with /method, /path and /extension matches only when all three do.
• Double quotes are globs, single quotes are regexes. "/content/*" matches anything under /content; '(GET|HEAD)' is a regular expression. Both must match the whole value.
• URLs split at the first dot. Dispatcher doesn’t know which nodes exist, so /content/site/page.model.json/x has path /content/site/page, selector model, extension json and suffix /x. A dot in a folder name, as in /etc.clientlibs, ends the path early.
• Selectors match one at a time. /selectors 'model' matches page.model.json and also page.model.infinity.json, which is why allow rules should use /url or /selectors ''.

When Dispatcher caches

A response is cached only when all of these hold: the method is GET or HEAD; the URL has an extension and doesn’t end in a slash; there’s no query string, or every parameter is ignored by /ignoreUrlParams; there’s no Authorization header or login-token cookie, unless /allowAuthorized "1"; and the last matching cache rule allows it. AEM can still stop caching with Dispatcher: no-cache or Cache-Control: no-cache, which the tester can’t see.

The security check

It tests requests a public site should refuse, including:

• /system/console, CRXDE and Package Manager;
• QueryBuilder, including the .json.servlet and .json/a.css bypasses;
• JSON and XML dumps of your content: .infinity.json, .-1.json, .1.json, .docview.xml;
• suffixes on pages, and POST to pages (the Sling POST servlet);
• /home/users, /apps, /libs, /etc and /var.

Set your content root (for example /content/mysite/en) so the content probes use your paths.

Limits

• $include files aren’t followed. Paste their rules in place of the include.
• Apache rewrites, vanity URLs and /virtualhosts aren’t applied: test the URL as Dispatcher receives it.
• Regular expressions run with JavaScript’s engine, which handles the patterns used in Dispatcher configs but may differ in rare edge cases.
• Response headers from AEM, /statfileslevel, /invalidate and TTLs aren’t simulated.