Edge Functions

Running custom code during traffic processing

Overview

An Edge Function (EF) allow you to extend Link11 WAAP's tools and functionality. An EF consists of Lua code that can be run at different points in L11WAAP's traffic processing.

An EF can be configured to execute before any other processing occurs. Therefore, it can override or preempt other configured settings within L11WAAP.

Or, it can be run after traffic filtering has been completed. An example use case is custom logic based on the tags that Link11 WAAP attached to the request.

When an admin creates an Edge Function, L11WAAP validates the code with a Lua compiler. If any syntax errors are found, an error message will be shown. However, Link11 does not validate the code beyond this. Please ensure that the code is valid and tested before adding it. If the code has errors, undefined behavior can occur when L11WAAP attempts to execute it.

Edge Functions are a very powerful tool. If you need assistance with this feature, please feel free to contact support.

Usage within applications and APIs

Edge Functions are assigned to destination paths/URLs within Security Policies.

Out of the box, L11WAAP includes a number of Edge Functions. Initially, they are not assigned to any Security Policies, and thus, are inactive by default.

Administration

The main window (shown above) lists all current Edge Functions.

The administration (addition/deletion/editing/versioning) of EFs follows the conventions described here.

Parameters

Name

A name for this EF, to be used within the interface.

Description

Information about this EF, for use within the interface.

Phase

This specifies when the Edge Function code will be executed.

Phase	Description
Request Pre Processing	Executes immediately when L11WAAP receives an incoming request, before any other processing occurs. Runs before the security logic. Cannot be preempted/prevented by the security logic, since it executes beforehand. A request might only be blocked here if NGINX itself blocks it (e.g., due to malformed headers or connection limits).
Request Post Processing	Executes after L11WAAP has finished processing the request, and before it sends the request to the backend server. Runs after the security logic. Will only be reached if the request is allowed by the security logic. If the request is blocked, this stage will not be executed.
Response Pre Processing	Executes when L11WAAP receives the response from the backend. Runs on the response coming back from the origin, before any potential processing. The response cannot be blocked here, as L11WAAP does not evaluate or filter responses from the origin at this stage (unless NGINX does it for some reason).
Response Post Processing	Executes as the last action before L11WAAP sends the response to the client. Runs after the response has been processed (e.g., the addition of the upstream-status tag) and just before it is sent to the client. Similar to the previous stage, since there is no security logic evaluating responses, this function cannot be blocked and will execute as normal.

Code

The Lua code for the Edge Function.

Connections to Security Policies

The list of Security Policies that include this Edge Function. Each Security Policy defines the scope (i.e., the paths within Backend Services) for which the Function will be active.

For a discussion of how to use this control, see Connections to Security Policies.

Examples

Out of the box, Link11 WAAP includes multiple Edge Functions. These can be studied as good illustrations of how to create and use Edge Functions.

Custom function for accessing Tag data

A use case that sometimes arises is to access the Tags attached to the request during L11WAAP's processing, for case-specific purposes (business logic, customized responses, etc.)

This can be done in the Request Post Processing phase, with a custom function [ngx.tag_exist] that returns a boolean. Its usage is as follows:

// returns true if tag1 was attached to the request, false otherwise
ngx.tag_exist("tag1")

// returns true if tag1 AND tag2 were attached to the request, false otherwise
ngx.tag_exist("tag1","tag2")

// returns true if tag1 OR tag2 were attached to the request, false otherwise
ngx.tag_exist("tag1") || ngx.tag_exist("tag2")

For example, L11WAAP includes a default Global Filter that adds a tag (cloudfront) to all requests bearing an AWS CloudFront IP. An Edge Function can pass this information to the origin in a header named "is-cloudfront", like this:

ngx.header["is-cloudfront"] = ngx.tag_exist("cloudfront")