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 .