Policy Rules
RequestPolicy 1.0+ supports two types of rule actions: "allow" and "block".
Every rule can specify origins and/or destinations that match
the rule. When a rule matches a request, the rule's action (allow or block)
is triggered. When both an allow and a block rule match a request, the user's
default rule is used.
The origin and destination components of a rule can have the following
properties. All properties are optional. An empty rule property will not be
considered when matching against requests.
- Scheme
- The URL's scheme (protocol). For example, "http" or "https".
- Host
- The URL's host. For example, "example.com", "1.2.3.4", or
"fe80:0000:0000:0000:0202:b3ff:fe1e:8329". For host names (not IP
addresses), you can use a wildcard to indicate any or no subdomain. For
example, "*.example.com" will match "example.com", "www.example.com", or
"a.b.c.example.com". Wildcards are only supported as the leftmost label of a
hostname. Wildcards are not supported anywhere else in the name and cannot
be mixed with other characters.1
- Port
- The URL's port. For example, "81" or "8080. This may also be "*" to
indicate that any ports should match. By default, rules that do not specify
ports only match the default port for the request's scheme.2
- Path
- The URL's path. Note: this is planned but not yet implemented. When
implemented, this will support either regular expressions or path prefixes.
[1] The restrictions on the host value of rules
exists for performance reasons. Allowing regular expressions would mean that
every rule with regular expressions would have to be checked for every
request. In the future we may add support for regular expressions in host
patterns. We may also add support for CIDR notation and IPv6 abbreviated
notation.
[2] TODO: confirm this is true.