Configuration Options

The HUMAN Enforcer for Fastly Compute (Rust) is configured through the PXConfig Config Store. Each configuration is stored as a px_* key-value pair, loaded at startup by the Enforcer. When the kv_store feature is enabled, the same keys are read from (and persisted to) a Fastly KV Store instead.

A small number of options are runtime-only callbacks that cannot be expressed as Config Store values. These are set directly on the Enforcer in your Rust code before calling px.enforce() and are documented in Runtime callbacks.

Configuration types

The Config Store stores every value as a string. The Enforcer parses each value according to the type of the configuration:

• String: A sequence of characters, without quotes. Example: my_string
• Boolean: A true or false value. Example: true
• Number: A numeric value. Example: 100
• List: A comma-separated list of values without quotes. Example: value1, value2
• Regex list: A comma-separated list of regular expressions without quotes. Example: ^/graphql$, ^/api/graphql$
• Object: A JSON-encoded value. Used by px_login_credentials_extraction.

Configuration format

Add each configuration to the Fastly Config Store as a key-value pair. Enter both the key name and the value without quotes. For array or list values, separate items with commas.

Quick reference

Required

Optional

Deploying the configurations

To manually add or update the configurations, use Config Stores in the Fastly web UI. The configurations should be added to the Config Store named PXConfig as key-value pairs.

We also provide the pxconfig.sh script to populate the Config Store automatically. The following is an example to populate the required configurations only:

Required options:
-s, --service-id=SERVICE_ID       specify a service to deploy the dictionary
-v, --version=VER                 specify a service version
-a, --appid=APPID                 specify an appid
-c, --cookie_secret=SECRET        specify a cookie_secret
-t, --auth_token=TOKEN            specify an auth_token

Required configurations

These configurations are necessary for the Enforcer’s basic functionality.

px_app_id

The HUMAN application ID. Required to initialize the Enforcer. It is also used in activities, Risk API calls, and to derive the default HUMAN hosts.

Default: ""

key: px_app_id
value: PX12345678

px_cookie_secret

The secret used to validate risk cookies, PXDE cookies, and telemetry commands. Required to initialize the Enforcer.

Default: ""

key: px_cookie_secret
value: <COOKIE_SECRET>

px_auth_token

The bearer token used when sending Risk API, async activity, and telemetry requests. Required to initialize the Enforcer.

Default: ""

key: px_auth_token
value: <AUTH_TOKEN>

Basic configurations

px_module_enabled

This boolean serves as an on/off switch for the entire module, providing a way to enable and disable all Enforcer capabilities quickly and easily. When disabled, requests pass through without verification.

Default: false

key: px_module_enabled
value: true

px_module_mode

Controls the behavior of the Enforcer by changing how it executes parts of the workflow. This allows for analysis and fine-tuning of the Enforcer behavior without serving block pages that affect end users.

Possible values:

• "monitor" - The Enforcer performs all functions without returning block responses.
• "active_blocking" - The Enforcer returns block responses when needed.

Default: "monitor"

key: px_module_mode
value: active_blocking

px_debug

Enables verbose PerimeterX debug logs for this Fastly implementation. Not recommended for production environments.

Default: false

key: px_debug
value: true

px_blocking_score

The minimum score, inclusive, that should result in a block for the Cookie V3 / Risk API flows.

Default: 100

key: px_blocking_score
value: 80

px_s2s_timeout

The maximum time, in milliseconds, to wait for the Risk API request. If this timeout is reached, the original request is allowed to pass (fail open).

Default: 2000

key: px_s2s_timeout
value: 1000

px_token_version

The risk-cookie / mobile token format version expected by the validators.

Possible values: "2", "3".

Default: "3"

key: px_token_version
value: 3

px_user_agent_max_length

The maximum length of the User-Agent header used for risk cookie validation. If the user agent value exceeds this length, it is truncated to this length prior to processing.

Default: 8528

key: px_user_agent_max_length
value: 2048

px_risk_cookie_max_length

The maximum risk cookie value length accepted before validation fails.

Default: 2048

key: px_risk_cookie_max_length
value: 4096

px_risk_cookie_min_iterations

The minimum accepted PBKDF2 iteration count for Cookie V3 validation.

Default: 500

key: px_risk_cookie_min_iterations
value: 500

px_risk_cookie_max_iterations

The maximum accepted PBKDF2 iteration count for Cookie V3 validation.

Default: 5000

key: px_risk_cookie_max_iterations
value: 5000

Request handling

px_sensitive_headers

The HUMAN detector requires information about the HTTP request as part of its bot detections. Certain headers may contain information that should not be forwarded to other servers, including the HUMAN backend. Header names configured here are removed from requests sent by the Enforcer to the Risk API and async activities.

Default: Cookie, Cookies

key: px_sensitive_headers
value: x-sensitive-token

px_sensitive_routes

Certain endpoints may require more stringent protection from bot attacks (for example, endpoints that execute payments or handle personal information). Path prefixes configured as sensitive routes always trigger a Risk API call, even if the request contains a valid, unexpired cookie.

Default: []

key: px_sensitive_routes
value: /login, /checkout

px_sensitive_routes_regex

Regular expression routes with the same sensitive-route semantics as px_sensitive_routes. A request whose path matches any of the configured regexes always triggers a Risk API call.

Default: []

key: px_sensitive_routes_regex
value: ^/login$, ^/api/.*/checkout$

px_filter_by_route

Route prefixes specified here are not enforced, regardless of the score they receive. A request to a filtered route is removed from the enforcement flow before context creation and does not generate any risk or async activities.

Default: []

key: px_filter_by_route
value: /filtered_route

px_filter_by_extension

HUMAN does not enforce static assets such as images and documents. To prevent unnecessary API calls and computation, the Enforcer filters requests with a valid static file extension. Filtering by extension only applies to GET and HEAD requests.

Default: .css, .bmp, .tif, .ttf, .docx, .woff2, .js, .pict, .tiff, .eot, .xlsx, .jpg, .csv, .eps, .woff, .xls, .jpeg, .doc, .ejs, .otf, .pptx, .gif, .pdf, .swf, .svg, .ps, .ico, .pls, .midi, .svgz, .class, .png, .ppt, .mid, .webp, .jar, .json, .xml

key: px_filter_by_extension
value: .css, .js, .png

px_filter_by_user_agent

Filters out requests according to their user-agent value, avoiding unnecessary traffic in the enforcement flow and reducing operating costs.

Default: []

key: px_filter_by_user_agent
value: filtered_UA

px_filter_by_ip

Filters out requests according to their client IP, avoiding unnecessary traffic in the enforcement flow and reducing operating costs.

Default: []

key: px_filter_by_ip
value: 1.1.1.1, 2.2.2.2

px_filter_by_http_method

Filters out requests according to their HTTP method, avoiding unnecessary traffic in the enforcement flow and reducing operating costs.

Default: []

key: px_filter_by_http_method
value: OPTIONS, DELETE

px_custom_cookie_header

The Enforcer attempts to extract the HUMAN cookies from the Cookie header. If the HUMAN cookies are transferred on a different header, configure that header name here.

Default: x-px-cookies

key: px_custom_cookie_header
value: x-custom-cookies

px_enforced_routes

Customers may want certain, but not all, endpoints to be enforced by HUMAN even when the Enforcer is in monitor mode. These routes go through the full enforcement workflow, including blocking requests when necessary.

Default: []

key: px_enforced_routes
value: /enforced_route

px_monitored_routes

Enables certain endpoints to be monitored rather than enforced by HUMAN, even when the Enforcer is in active blocking mode.

Default: []

key: px_monitored_routes
value: /monitored_route

px_bypass_monitor_header

When enabling the Enforcer for the first time, it is recommended to do so in monitor mode to collect data before blocking user requests. This feature activates the full blocking flow while in monitor mode when a request contains this header with the value 1.

Default: x-px-block

key: px_bypass_monitor_header
value: x-bypass-monitor

px_ip_headers

By default, the IP is taken from the client connection. If this value is inaccurate, the Enforcer can extract the IP from the headers configured here. The headers are traversed in the order they are listed, and the first header value that exists is used as the client IP.

Default: []

key: px_ip_headers
value: true-client-ip, x-forwarded-for

px_extracted_cookies

Cookie names whose values are copied into the Risk API additional fields.

Default: []

key: px_extracted_cookies
value: _ga, session_id

First-party

px_first_party_enabled

To prevent suspicious or unwanted behavior on the client side, some browsers or extensions (for example, ad blockers) may deny the frontend JavaScript code from making requests to other domains. This prevents the HUMAN sensor from reaching the HUMAN backends, which limits detection capabilities. First-party mode enables the Enforcer to act as a proxy for the HUMAN servers and serve content from a first-party endpoint on the customer’s domain.

Default: true

key: px_first_party_enabled
value: false

px_custom_first_party_sensor_endpoint

For an application with ID PX12345678, the first-party sensor endpoint is /12345678/init.js by default. This configuration customizes the first-party sensor script endpoint. The Enforcer continues to proxy first-party requests that match the default pattern in addition to the configured path.

Default: ""

key: px_custom_first_party_sensor_endpoint
value: /human_sensor

px_custom_first_party_xhr_endpoint

For an application with ID PX12345678, the first-party XHR endpoint is /12345678/xhr by default. This configuration customizes the first-party XHR endpoint. The Enforcer continues to proxy first-party requests that match the default pattern in addition to the configured path.

Default: ""

key: px_custom_first_party_xhr_endpoint
value: /human_xhr

px_custom_first_party_captcha_endpoint

For an application with ID PX12345678, the first-party captcha endpoint is /12345678/captcha by default. This configuration customizes the first-party captcha endpoint. The Enforcer continues to proxy first-party requests that match the default pattern in addition to the configured path.

Default: ""

key: px_custom_first_party_captcha_endpoint
value: /human_captcha

Block page customization

px_custom_logo

Adds a custom logo to the block page that is shown to users. This aligns the block page with the customer’s brand. An empty value keeps the logo hidden.

Default: ""

key: px_custom_logo
value: https://www.example.com/custom_logo.png

px_js_ref

Provides a way to include a custom JavaScript file on the block page. This script runs after the default block-page scripts.

Default: ""

key: px_js_ref
value: https://www.example.com/custom_script.js

px_css_ref

Provides a way to include an additional custom CSS file on the block page.

Default: ""

key: px_css_ref
value: https://www.example.com/custom_style.css

Header data enrichment

px_data_enrichment_header_name

The request header name used to forward the verified PerimeterX Data Enrichment (PXDE) JSON to the origin. An empty value disables this feature.

Default: ""

key: px_data_enrichment_header_name
value: x-human-data-enrichment

PXHD cookie

px_secured_pxhd_enabled

Whether the _pxhd cookie set on the HTTP response should include the Secure attribute.

Default: false

key: px_secured_pxhd_enabled
value: true

Logging

px_log_endpoint

The name of the Fastly logging endpoint used by platform-specific activity delivery.

Default: ""

key: px_log_endpoint
value: Human-Log

px_logger_auth_token

The token used to authenticate with HUMAN’s enforcer logging services. This value is required for setting up the header-based logger feature.

Default: ""

key: px_logger_auth_token
value: <LOGGER_AUTH_TOKEN>

CORS support

CORS (Cross-Origin Resource Sharing) is a mechanism that enables the server to indicate when a request contains cross-origin resources. It does so by adding special HTTP headers to the request, which permits the browser to load these resources. Without these headers, the browser may block requests to these resources for security reasons.

In most cases, CORS employs a two-stage procedure with a preliminary “preflight” request followed by the actual request. To learn more about different request types, see these examples.

px_cors_support_enabled

Enables CORS handling for preflight and block responses. When enabled, the Enforcer automatically adds the following default CORS response headers to block responses resulting from CORS requests:

Access-Control-Allow-Origin: <ORIGIN_REQUEST_HEADER_VALUE>
Access-Control-Allow-Credentials: true

It also activates the custom block response headers callback and the px_cors_preflight_request_filter_enabled and custom preflight handler options.

Default: false

key: px_cors_support_enabled
value: true

Cors custom block response headers callback

If the default CORS response headers are not sufficient, it is possible to completely customize the headers that should be added to all block responses resulting from CORS requests. If a callback function is defined, the default headers are not added; only those headers specified in the returned vector are added to the block response.

Function definitions:

1
pub type PXCorsCustomBlockResponseHeadersFn =
2
    fn(req: &Request, conf: &PXConfig) -> Vec<(String, String)>;
3
4
pub fn set_cors_create_custom_block_response_headers_fn(
5
    &mut self,
6
    f: PXCorsCustomBlockResponseHeadersFn,
7
)

Default: None

1
// callback function to create custom CORS headers for block responses
2
fn cors_block_response_headers(req: &Request, _conf: &PXConfig) -> Vec<(String, String)> {
3
    vec![
4
        (
5
            "Access-Control-Allow-Origin".to_string(),
6
            req.get_header_str("Origin").unwrap_or_default().to_string(),
7
        ),
8
        (
9
            "Access-Control-Allow-Credentials".to_string(),
10
            "true".to_string(),
11
        ),
12
        (
13
            "Access-Control-Allow-Methods".to_string(),
14
            "GET, POST, OPTIONS".to_string(),
15
        ),
16
        (
17
            "Access-Control-Allow-Headers".to_string(),
18
            "Content-Type, Authorization".to_string(),
19
        ),
20
    ]
21
}
22
23
...
24
25
px.set_cors_create_custom_block_response_headers_fn(cors_block_response_headers);

px_cors_preflight_request_filter_enabled

This configuration disables enforcement for CORS preflight requests. When set to true, CORS preflight requests are filtered from the enforcement flow. That is, they pass through without triggering detection or block responses.

Default: false

key: px_cors_preflight_request_filter_enabled
value: true

Cors custom preflight handler

If a more customized approach is needed for handling CORS preflight requests, this custom function can be set to define the desired behavior. The custom function receives the original HTTP request and returns an object representing the HTTP response to be returned. If None is returned, the Enforcer continues processing the preflight request.

Function definitions:

1
pub type PXCorsCustomPreflightHandlerFn =
2
    fn(req: &Request, conf: &PXConfig) -> Option<Response>;
3
pub fn set_cors_custom_preflight_handler_fn(
4
    &mut self, f: PXCorsCustomPreflightHandlerFn);

Default: None

1
// callback function to handle CORS preflight requests
2
fn cors_preflight_handler(req: &Request, _conf: &PXConfig) -> Option<Response> {
3
    if !req.get_method_str().eq_ignore_ascii_case("OPTIONS")
4
        || !req.contains_header("Origin")
5
        || !req.contains_header("Access-Control-Request-Method")
6
    {
7
        return None;
8
    }
9
10
    let mut response_headers = HashMap::new();
11
    response_headers.insert(
12
        "Access-Control-Allow-Origin",
13
        req.get_header_str("Origin").unwrap_or_default(),
14
    );
15
    response_headers.insert(
16
        "Access-Control-Allow-Methods",
17
        req.get_header_str("Access-Control-Request-Method")
18
            .unwrap_or_default(),
19
    );
20
    response_headers.insert(
21
        "Access-Control-Allow-Headers",
22
        req.get_header_str("Access-Control-Request-Headers")
23
            .unwrap_or_default(),
24
    );
25
    response_headers.insert("Access-Control-Allow-Credentials", "true");
26
    response_headers.insert("Access-Control-Max-Age", "86400");
27
28
    let mut response = Response::new();
29
    response.set_status(fastly::http::StatusCode::NO_CONTENT);
30
    for (name, value) in response_headers {
31
        response.set_header(name, value);
32
    }
33
34
    Some(response)
35
}

GraphQL support

px_graphql_enabled

Whether the Enforcer should attempt to parse and report information about GraphQL operations on incoming requests. When enabled, all POST requests with routes that match px_graphql_routes have their bodies parsed for GraphQL operations.

Default: false

key: px_graphql_enabled
value: true

px_graphql_routes

A comma-separated list of regex routes that are checked for GraphQL operations. If a request’s route matches any of the regexes in this list, it is checked for sensitive GraphQL operations as configured in px_sensitive_graphql_operation_types and px_sensitive_graphql_operation_names.

Default: ^/graphql$

key: px_graphql_routes
value: ^/graphql$, ^/api/graphql$

px_sensitive_graphql_operation_types

A comma-separated list of operation types (query, mutation, or subscription) that should be considered sensitive. If one or more GraphQL operations on a request has a type matching this list, it triggers a Risk API call even if the request contains a valid, unexpired cookie.

Default: []

key: px_sensitive_graphql_operation_types
value: mutation, subscription

px_sensitive_graphql_operation_names

A comma-separated list of operation names or keywords that should be considered sensitive. If a GraphQL operation has a name or extracted keyword that matches one of the configured items, the request triggers a Risk API call even if it contains a valid, unexpired cookie.

Default: []

key: px_sensitive_graphql_operation_names
value: SensitiveOperation1, SensitiveOperation2

px_graphql_keywords

A comma-separated list of regular expressions used to identify important terms from GraphQL operation queries. Strings in a GraphQL query that match the patterns configured here are extracted and reported to HUMAN. These keywords help determine the purpose of the operation (for example, login, checkout, search) and can also mark operations as sensitive via px_sensitive_graphql_operation_names.

Default: []

key: px_graphql_keywords
value: performLogin, addToCart

px_graphql_body_max_length

The maximum body prefix length, in bytes, read while parsing the GraphQL JSON body.

Default: 1048576

key: px_graphql_body_max_length
value: 524288

Agentic Trust

px_agentic_trust_enabled

Enables agentic trust verification for Model Context Protocol (MCP) requests.

Default: false

key: px_agentic_trust_enabled
value: true

px_agentic_trust_mcp_endpoint_path

The MCP endpoint path used for agentic trust verification.

Default: /mcp/

key: px_agentic_trust_mcp_endpoint_path
value: /mcp/

Users identifiers

These configurations enable extracting user identifiers from a JWT carried on the request, either in a cookie or a header.

px_jwt_cookie_name

The name of the cookie that contains the JWT from which user identifiers should be extracted.

Default: ""

key: px_jwt_cookie_name
value: auth

px_jwt_cookie_user_id_field_name

The dot path of the field in the JWT payload (extracted from the JWT cookie) that contains the user ID to be reported.

Default: ""

key: px_jwt_cookie_user_id_field_name
value: nameID

px_jwt_cookie_additional_field_names

The dot paths of additional fields in the JWT payload (extracted from the JWT cookie) to be reported in addition to the user ID.

Default: []

key: px_jwt_cookie_additional_field_names
value: exp, iss

px_jwt_header_name

The name of the header that contains the JWT from which user identifiers should be extracted.

Default: ""

key: px_jwt_header_name
value: x-jwt-authorization

px_jwt_header_user_id_field_name

The dot path of the field in the JWT payload (extracted from the JWT header) that contains the user ID to be reported.

Default: ""

key: px_jwt_header_user_id_field_name
value: sub

px_jwt_header_additional_field_names

The dot paths of additional fields in the JWT payload (extracted from the JWT header) to be reported in addition to the user ID.

Default: []

key: px_jwt_header_additional_field_names
value: exp, iss

Credential Intelligence

Credential Intelligence detects the use of compromised credentials. To enable it, set px_login_credentials_extraction_enabled to true and define the credential endpoints in px_login_credentials_extraction.

px_login_credentials_extraction_enabled

Enables the extraction and reporting of credentials from the Enforcer. This must be set to true to enable the Credential Intelligence product.

Default: false

key: px_login_credentials_extraction_enabled
value: true

px_login_credentials_extraction

A JSON-encoded array of configuration objects, one per credential endpoint. Each object describes how to identify credential-bearing requests, how to extract the credentials, and how to determine whether the login operation was successful based on the returned HTTP response.

Default: []

1
[
2
    {
3
        "path": "/login",
4
        "path_type": "regex",
5
        "method": "POST",
6
        "sent_through": "body",
7
        "user_field": "username",
8
        "pass_field": "password",
9
        "login_successful_reporting_method": "status",
10
        "login_successful_statuses": [200, 202]
11
    }
12
]

Each credential endpoint configuration object contains the following fields:

path

Required. The path of the request that contains the credentials. It must an exact path or a string in the form of a regular expression.

path_type

Optional. Whether the incoming request path is evaluated against the configured path as a regular expression or as an exact match.

Possible values:

• "exact" - The value set in path must match the request path exactly.
• "regex" - The value set in path is a regular expression matched against the request path.

Default: "exact"

method

Required. The HTTP method of the request that contains the credentials (for example, "GET", "POST", "PUT").

sent_through

Required. Where the credentials should be extracted from.

Possible values:

• "body" - The credentials are extracted according to user_field and pass_field from the request body.
• "header" - The credentials are extracted from the request headers according to user_field and pass_field.
• "query-param" - The credentials are extracted from the query parameters according to user_field and pass_field.
• "custom" - The credentials are extracted by the custom credential extraction callback.

user_field

Required only if sent_through is set to "body", "header", or "query-param". The name of the field, header, or query parameter where the username can be found. For JSON bodies, nested subfields can be separated with periods (for example, user_info.username).

pass_field

Required only if sent_through is set to "body", "header", or "query-param". The name of the field, header, or query parameter where the password can be found. For JSON bodies, nested subfields can be separated with periods.

protocol

Optional. Whether to process credentials as part of a single or multiple HTTP requests.

Possible values:

• "v2" - Both username and password are present on the same HTTP request and must be extracted successfully to trigger Credential Intelligence.
• "multistep_sso" - The username and password are delivered on different HTTP requests. Either one, but not both, must be extracted successfully.
• "both" - The credentials may be present on the same request or on different requests, handled according to v2 or multistep_sso accordingly.

Default: "both"

login_successful_reporting_method

Required. The method by which the Enforcer determines whether the login request was successful.

Possible values:

• "status" - Evaluate the response status code against login_successful_statuses.
• "body" - Evaluate the response body against login_successful_body_regex.
• "header" - Evaluate the response headers against login_successful_header_name and login_successful_header_value.
• "custom" - Invoke the custom login-success callback.

Default: "status"

login_successful_statuses

Optional. An array of HTTP statuses signifying a successful login. Takes effect only when login_successful_reporting_method is "status".

Default: [200]

login_successful_body_regex

Required only if login_successful_reporting_method is set to "body". A regular expression against which the response body is evaluated. A match indicates a successful login.

Default: ""

login_successful_header_name

Required only if login_successful_reporting_method is set to "header". A response header name signifying a successful login. If login_successful_header_value is empty, any response containing this header name is considered a successful login.

Default: ""

login_successful_header_value

Optional. If configured, a login attempt is considered successful only if the response contains login_successful_header_name with a value exactly equal to this configuration. Takes effect only when login_successful_reporting_method is "header".

Default: ""

px_credentials_intelligence_version

The default credential hashing protocol applied to endpoints that do not specify a protocol field. Possible values: v2, multistep_sso, both.

Default: both

key: px_credentials_intelligence_version
value: both

px_compromised_credentials_header

The header name set on the incoming origin request when the credentials are compromised. When added, its value is always 1. If credentials are not compromised, the header is not added.

Default: px-compromised-credentials

key: px_compromised_credentials_header
value: x-ci-compromised

px_send_raw_username_on_additional_s2s_activity

Whether to report the raw username on the additional_s2s activity. When set to false, the raw username is never reported. When set to true, the raw username is reported only if the credentials are compromised and the login request was successful.

Default: false

key: px_send_raw_username_on_additional_s2s_activity
value: true

px_additional_s2s_activity_enabled

Whether to send the additional_s2s activity automatically after the response. This should only be set to false if it is not possible to determine whether the login was successful based on the HTTP response, in which case the activity must be sent in some other way.

Default: true

key: px_additional_s2s_activity_enabled
value: false

px_additional_s2s_activity_header_enabled

Whether to attach the additional_s2s payload and URL as headers to the original request, so the activity can be enriched with the proper login_successful value and sent at a later stage. This should only be enabled if px_additional_s2s_activity_enabled is set to false.

When set to true, the following headers are added to the origin request:

• px-additional-activity - A JSON object containing the payload of the additional_s2s activity.
• px-additional-activity-url - The URL to which the payload should be sent as an HTTP POST request.

Default: false

key: px_additional_s2s_activity_header_enabled
value: true

px_login_successful_reporting_method

The default login-success detection method applied to endpoints that do not override it. See login_successful_reporting_method for the possible values.

Default: status

key: px_login_successful_reporting_method
value: custom

px_login_successful_status

The default HTTP status codes that mean a login was successful. This takes effect when the reporting method is status.

Default: 200

key: px_login_successful_status
value: 200, 202

px_login_successful_body_regex

The default body regex for login-success detection. This takes effect when the reporting method is body.

Default: ""

key: px_login_successful_body_regex
value: Welcome, [A-Za-z0-9_]+!

px_login_successful_header_name

The default response header name for login-success detection. This takes effect when the reporting method is header.

Default: ""

key: px_login_successful_header_name
value: x-login-successful

px_login_successful_header_value

The default response header value for login-success detection. This takes effect when the reporting method is header.

Default: ""

key: px_login_successful_header_value
value: logged-in

Runtime callbacks

Some behaviors cannot be expressed as Config Store values and are instead registered as runtime callbacks in your Rust code before calling px.enforce(). The CORS callbacks are documented under CORS support.

px_enrich_custom_parameters

Enriches activities sent from the Enforcer to HUMAN with up to ten additional custom parameters on Risk and async activities. Registered via set_enrich_custom_params_fn.

1
pub type PXEnrichCustomParamsFn =
2
    fn(req: &Request, conf: &PXConfig, params: &mut PXCustomParams);
3
4
pub fn set_enrich_custom_params_fn(&mut self, f: PXEnrichCustomParamsFn);

px_custom_is_sensitive_request

Marks a request as sensitive based on custom logic. A sensitive request triggers a Risk API call even if it contains a valid, unexpired cookie. Registered via set_is_sensitive_request_fn.

1
pub type PXIsSensitiveRequestFn = fn(req: &Request, conf: &PXConfig) -> bool;
2
3
pub fn set_is_sensitive_request_fn(&mut self, f: PXIsSensitiveRequestFn);

px_filter_by_custom_function

Filters a request from the enforcement flow based on custom logic. A filtered request is not blocked and does not generate any risk or async activities. Registered via set_is_filtered_request_fn.

1
pub type PXIsFilteredRequestFn = fn(req: &Request, conf: &PXConfig) -> bool;
2
3
pub fn set_is_filtered_request_fn(&mut self, f: PXIsFilteredRequestFn);

px_additional_activity_handler

Runs after the page_requested or block activity is sent to the Collector, and before the request is forwarded to the next step. A common use case is to set the score as a header that the application can read. Registered via set_additional_activity_handler_fn.

1
pub type PXAdditionalActivityHandlerFn =
2
    fn(req: &Request, conf: &PXConfig, ctx: &PXContext);
3
4
pub fn set_additional_activity_handler_fn(&mut self, f: PXAdditionalActivityHandlerFn);

Custom credential extraction

Registered via set_ci_extract_credentials_fn and used by credential endpoints configured with sent_through: custom. It returns the raw credentials extracted from the request, or None if neither field can be extracted.

1
pub type PXExtractCredentialsFn =
2
    fn(req: &Request, endpoint_index: usize) -> Option<PXRawCredentials>;
3
4
pub fn set_ci_extract_credentials_fn(&mut self, f: PXExtractCredentialsFn);

Custom login-success reporting

Registered via set_ci_login_successful_fn and used by credential endpoints configured with login_successful_reporting_method: custom. It returns whether the login attempt was successful based on the HTTP response.

1
pub type PXLoginSuccessfulFn =
2
    fn(resp: &Response, endpoint_index: usize) -> Option<bool>;
3
4
pub fn set_ci_login_successful_fn(&mut self, f: PXLoginSuccessfulFn);