Allow rule configuration

You can edit an allow rule by clicking on it in the list. To add a new rule, you click on the final entry in the list, which says New entry.

When creating a new allow rule, you must at least provide a unique rule name and a path pattern. For the other fields the default values work without a change. The comment field is optional and helps to document your allow rule.

You can use the patterns defined on the Filter patterns page to configure the patterns for HTTP method and Request content type. The default patterns used are not very restrictive and it is recommended to define your own patterns to restrict the set of allowed HTTP requests to your applications.

In the bottom section of the configuration page, you can create criteria for the parameters of the evaluated HTTP request. The evaluation logic for the parameters is similar to the overall logic of allow rules: You can specify parameter rules (one per line) that parameters must satisfy if the parameter is applicable for the parameter rule.

0. For each parameter, the same two conditions apply:
1. There must be at least one applicable parameter rule.
2. Each applicable parameter rule must be satisfied by the parameter.

A parameter rule is applicable if the parameter name pattern matches the parameter name.

A parameter rule is satisfied by a parameter if the parameter value is matched by the parameter value pattern.

If there is no parameter rule, no parameters are allowed for the HTTP request. On the other hand, if there are some parameter rules marked as mandatory (Mand.), there must be at least one parameter present for which the parameter rule is applicable or the HTTP request does not satisfy the allow rule.

Filter Patterns are used, to be able to reuse a specific already defined filter.

Pattern Editor

On the filter patterns configuration page it is possible to add new filter expression patterns and modify existing patterns. Allow rules are always application- (or mapping-) specific, that's why there is no global list of allow rules. However, it is possible to copy existing patterns used in other mappings, if they are of the same pattern type. For more details about editing or testing a pattern, check the pattern editor pop-up documentation.

• URL path pattern (absolute external URL path including filename)
• HTTP method
• Content type
• Parameter values

There are no filter patterns for parameter names.

A filter pattern contains a unique pattern name, a description (comment), and the regular expression pattern itself. For each pattern, the Ignore Case check-box defines if the pattern should be applied case sensitive or not. In addition, there is an Invert check-box for each pattern, that lets you define if the inverted value of the regular expression should be used.

Please refer to Regular Expressions basic examples for details on regular expressions.

If one or more individual allow rules are set to "Log only", all requests are passed to the back-end server, regardless of whether they satisfy the remaining rules or not.

Suppose you have a mapping with two active allow rules, the (default) allow rule and a custom allow rule Wiki_action.

Let's see how these allow rules are applied to the following request:

copy

GET /dokuwiki/doku.php?id=mydocument&date=20070305&fromdate=20101231

How to read the request:

First of all, the request path matches the path patterns of both rules, the (default) allow rule (.*) and our custom Wiki_action rule (^/dokuwiki/doku.php$). All other conditions defined in these two rules must therefore be met, too.

The GET method is all right since the (default) allow rule allows GET and POST requests. The (default) allow rule has no further restrictions on content type, or parameters - in fact, it allows parameters with any name or value.

Let us move on to the Wiki_action allow rule. Again, there is no restriction on content type or client address, not even on the HTTP method. But this allow rule has two parameter rules: The first rule restricts the value of parameters containing the word date in their name: it is applicable for both parameters, date and fromdate , and parameter values satisfy the value pattern (any number of digits). The second parameter rule (.*) allows further parameters with any value. The id parameter falls into this category - the request would not be allowed without this parameter rule.

Airlock Gateway automatically generates parameters from JSON objects. These JSON parameters are treated like parameters in GET or POST requests. For details please refer to the JSON filtering page.