Chapter 5. Integrating a policy chain with APIcast native deployments For native APIcast deployments, you can integrate a custom policy chain by specifying a configuration file using the THREESCALE_CONFIG_FILE environment variable. The following example specifies the config file example.json : 5.1. Using variables and filters in policies Some standard policies support Liquid templating that allows using not only plain string values, but also variables that are present in the context of the request. To use a context variable, wrap its name in {{ and }} , example: {{ uri }} . If the variable is an object, you can also access its attributes, for example: {{ somevar.attr }} . Following are the standard variables that are available in all the policies: uri The path of the request with query parameters excluded from this path. The value of the embedded NGINX variable USDuri . host The host of the request, which is the value of the embedded NGINX variable USDhost . remote_addr The IP address of the client, which is the value of the embedded NGINX variable USDremote_addr . headers The object containing the request headers. Use {{headers['Some-Header']}} to get a specific header value. http_method The request method: GET, POST, etc . These standard variables are used in the context of the request, but policies can add more variables to the context. A phase refers to all the execution steps that APIcast has. Variables can be used by all the policies in the policy chain, provided these cases: Within the same phase, if the variable is added in the policy and then used in the following policy after the addition. If a variable is added in a phase, this variable can be used in the phases. Following are some examples of variables that the standard 3scale APIcast policy adds to the context: jwt : A parsed JSON payload of the JWT token for OpenID Connect authentication. credentials : An object that holds the application credentials. Example: "app_id": "972f7b4f" , "user_key": "13b668c4d1e10eaebaa5144b4749713f" . service : An object that holds the configuration for the service that the current request is handled by. Example: the service ID would be available as {{ service.id }}. For a full list of objects and values available in the context, see Liquid context debug . The variables are used with the help of Liquid templates. Example: {{ remote_addr }} , {{ headers['Some-Header'] }} , {{ jwt.aud }} . The policies that support variables for the values have a special parameter, usually with the _type suffix, for example: value_type , name_type . that accepts two values: "plain" for plain text and "liquid" for liquid template. APIcast also supports Liquid filters that can be applied to the variables' values. The filters apply NGINX functions to the value of the Liquid variable. The filters are placed within the variable output tag {{ }} , following the name of the variable or the literal value by a pipe character | and the name of the filter. Examples: {{ 'username:password' | encode_base64 }} , where username:password is a variable. {{ uri | escape_uri }} . Some filters do not require parameters, so you can use an empty string instead of the variable. Example: {{ '' | utctime }} will return the current time in UTC time zone. Filters can be chained as follows: {{ variable | function1 | function2 }} . Example: {{ '' | utctime | escape_uri }} . Following is the list of the available functions: escape_uri unescape_uri encode_base64 decode_base64 crc32_short crc32_long hmac_sha1 md5 md5_bin sha1_bin quote_sql_str today time now localtime utctime cookie_time http_time parse_http_time

Commands:
THREESCALE_CONFIG_FILE=example.json bin/apicast