Request / response actions
Configuration of request and response actions

Enabling and disabling default actions

Various default request and response actions are preconfigured in the default mapping template but may be adjusted for specific mappings.

Actions must be referenced by their names and can be enabled or disabled. Matching of action names is case-insensitive.

The following example shows a configuration with the request action (default) Request header whitelist and the response action (default) Response header blacklist enabled:

apps:
- mappings:
  - name: test
    request:
      default_actions:
      - name: "(default) Request header whitelist"
        enabled: true
    response:
      default_actions:
      - name: "(default) Response header blacklist"
        enabled: true

Creating custom actions

Custom actions are created using sections apps[].mappings[].request.custom_actions for request actions and apps[].mappings[].response.custom_actions for response actions. The following action types are available:

  • Request and response action types
  • ●
    add_header
  • ●
    add_missing_header
  • ●
    add_or_replace_header
  • ●
    remove_header
  • ●
    rewrite_header_value
  • Request action types
  • ●
    header_redirect
  • ●
    geolocation_redirect
  • Response action types
  • ●
    rewrite_raw_cookie
  • ●
    rewrite_cookie

The different action types are described in detail in the following section: Action Types

As an example, let's define a custom response header with session timing information using the add_header response action. This action definition makes use of the rewrite variable %SESSIONTIMINGINFO%, which resolves to the remaining session idle timeout and lifetime:

apps:
- mappings:
  - name: test
    response:
      custom_actions:
      - add_header:
          name: "X-AIRLOCK-SESSION-TIMING"
          value: "%SESSIONTIMINGINFO%"

As a result, clients will receive information about the remaing session timing, which is managed by the Microgateway. Using this information, JavaScript running on client side may warn users about session timeouts proactively.

For a comprehensive list of options for the different action types, please refer to the DSL reference .