Installing the Enforcer
Prerequisites
In order to compile and deploy Fastly Compute Package, rust compiler and Fastly CLI must be installed and configured: Compute services
Communicate with the HUMAN Backend
For the Enforcer to communicate with HUMAN services, four backend servers must be added and configured in the Fastly UI (or by using the contrib/pxbackend.sh script).
Backend parameters (replace ${APP_ID} with your HUMAN Application ID):
- Name:
human_sapi, Address:sapi-${APP_ID}.perimeterx.net - Name:
human_collector, Address:collector-${APP_ID}.perimeterx.net - Name:
human_client, Address:client.perimeterx.net - Name:
human_captcha, Address:captcha.px-cdn.net
All HUMAN backends should use SSL/TLS. It is recommended to set both First byte (ms) and Between bytes (ms) to 1000 ms.
Module installation
Include perimeterx-fastly-enforcer dependency to Cargo.toml:
Module integration
To integrate the HUMAN Rust module into existing Rust code, initialize PXEnforcer, register any optional callbacks before calling enforce, and then send the request through the Enforcer. If enforce returns a response, return it immediately because it is a block or first-party response. Otherwise, continue to the origin and call post_enforce before returning the origin response:
PXEnforcer Setup
Initialize the PXEnforcer structure with the name of the Fastly Config Store. You can use the default name: perimeterx_fastly_enforcer::DEFAULT_CONFIGSTORE_NAME.
This function takes a request and returns an optional response for block or first-party requests:
At the end of request processing, call the following function to finalize HUMAN Enforcer response handling:
Access the PXContext structure through px.ctx():
To set custom parameter values, use the following callback type:
where:
req:fastly::Requestconf:PXConfigparams: modifiable structure withcustom_param1throughcustom_param10fields
To register the custom parameters callback, use the following setter:
Sample code
This example shows how to use the HUMAN Rust module with custom parameter enrichment, additional activity handling, sensitive request detection, filtered request detection, request-specific module mode, and context access:
Migration from 1.x version
Backend configuration
Version 1.x used a single Fastly backend for HUMAN communication. The new 2.x version uses four dedicated backends (replace ${APP_ID} with your HUMAN Application ID):
- Name:
human_sapi, Address:sapi-${APP_ID}.perimeterx.net - Name:
human_collector, Address:collector-${APP_ID}.perimeterx.net - Name:
human_client, Address:client.perimeterx.net - Name:
human_captcha, Address:captcha.px-cdn.net
This change separates the Risk API, activities, client-side assets, and CAPTCHA traffic. Keeping these destinations separate makes routing clearer, supports first-party and CAPTCHA flows, and allows each HUMAN service endpoint to be configured independently in Fastly.
To update an existing Fastly service in the web UI:
- Open the Fastly service that runs the Enforcer.
- Clone the active service version so the backend changes can be edited.
- Open the
Originsconfiguration page. - Add the four backends listed above. For each backend, set the backend name and address, enable SSL/TLS, and set the override host to the same value as the address.
- Set both
First byte (ms)andBetween bytes (ms)to1000ms for each HUMAN backend. - Save the changes and activate the new Fastly service version.
- Remove the old 1.x single HUMAN backend after you confirm the new version is serving traffic correctly.
PXContext fields
Many PXContext fields that were previously always present in 1.x version are now optional because they are only available after specific enforcement paths. For example, a request may not have a score, a Risk API call may not run, or data enrichment may not be returned. Access context through px.ctx() and handle Option<> values returned by the getter methods.
Examples: