The rule file

The "rule file" is a straightforward yaml file, shared between the three tool, containing a list of directives that fluxzy will evaluate during the proxying.

Here is a basic sample:

rules:
- filter: 
    type: HostFilter
    pattern: example.com
    operation: endsWith
  actions:
    - type: setRequestCookieAction
      name: my-session-cookie
      value: my-session-value
- filter: 
    type: PostFilter
  actions:
    - type: AddResponseHeaderAction
      headerName: X-Proxy
      headerValue: Passed through fluxzy
    - type: ForceHTTP11Action

The root element rules must be unique within the file and contains a list of one filter and multiple actions.

In this example, there are two distinct rules:

• The first rule, triggered when the Host the domain or the subdomain of example.com, will add a cookie to the request.
• The second rule, triggered when the HTTP method is POST, will add a response header and force the HTTP version to 1.1.

You have probably noted that inside a rule, there can be multiple actions for one filter. To enable multiple filtering, a special filter named FilterCollection can combine multiple filter with a merging operation (OR or AND). Children filters of this collection can also be another collection.

When the scope of two or more rules overlap, the order of evaluation will be the order of appearance in the file.

Finaly filter names and actions are case insensitive and suffix Filter and Action can be omitted.

You can define, reuse and extract variables during a capture session.

Inside a rule file, a variable can be called with the following syntax:

${user.VARIABLE_NAME}

The prefix user is mandatory to access to an user defined variable. Following the same syntax, a process environment variable can be accessed with the prefix env.

Extracting variable is done by filters based on string search operation. These type of filters can be identified by the property pattern and operation.

The extraction is triggered when the operation is a regex and the regex formula contains a named capture group.

For example, the following rule will extract a bearer token from any request :

- filter: 
    type: requestHeaderFilter
    name: Authorization
    pattern: Bearer (?<TOKEN>.+)
    operation: regex
  actions: 
    - type: stdOutAction
      text: Found token ${user.TOKEN}

We use the syntax ${user.TOKEN} to reference the variable extracted from a previous filter.

The prefix user is mandatory to access to an user defined variable.

fluxzy has some built-in variables related to the current processed exchange

Variable name	Description
authority.host	The destination host
authority.port	The destination port
authority.secure	true if the destination require https, false otherwise
exchange.id	Identifier of the exchange
exchange.url	The absolute url of the exchange
exchange.method	The request method
exchange.path	The path and query of the method
exchange.status	The HTTP response status
global.filterScope	The current filterScope. Values can be found here

The predefined variables will return an empty string when not set (example: the response was not received or aborted).

You can use SetVariableAction to define a variable from a rule file. You can find more on its dedicated page.

rules:
- filter: 
    type: PostFilter
  actions:
    - type: SetVariableAction
      # eval the action only when the response header is received
      scope: responseHeaderReceivedFromRemote 
      name: foo 
      value: bar