For AI agents: a documentation index is available at the root level at /llms.txt and /llms-full.txt. Append /llms.txt to any URL for a page-level index, or .md for the markdown version of any page.
HUMAN DashboardHUMAN WebsiteRequest a Demo
Product GuidesEnforcer GuidesMobile SDKAPI ReferenceCustomer support
Product GuidesEnforcer GuidesMobile SDKAPI ReferenceCustomer support
  • General
    • About Enforcers
    • Support first-party HUMAN calls
    • Troubleshoot Enforcer configurations
  • Enforcer frameworks
    • Akamai ESI
    • Apache - C Module
    • ASP.NET
    • Callout Enforcer
    • Envoy Proxy
    • F5 BIGIP
    • Fastly JavaScript Compute@Edge
    • Google Cloud Platform (GCP) Callout Enforcer
    • Kong Plugin
    • NGINX - C Module
    • NGINX - LUA Module
      • What's New
      • Supported Features
      • Installing the Enforcer
      • Configuration Options
      • Upgrading the Enforcer
      • HUMAN Plugin Configuration
      • First Party Configuration
      • Enrichment
    • PHP
    • Python
    • Ruby
    • Salesforce Commerce Cloud Cartridge
LogoLogo
Login
Login
HUMAN DashboardHUMAN WebsiteRequest a Demo
On this page
  • Data Enrichment
  • Log Enrichment
Enforcer frameworksNGINX - LUA Module

Enrichment

Was this page helpful?
Previous

What's New

Next
Built with

Data Enrichment

The HUMAN NGINX plugin stores the data enrichment payload on the request context. The data enrichment payload can also be processed with additional_activity_handler.

Only requests that are not blocked will reach the backend server, so specific logic must be applied to the processing function.

The following example includes the pre-condition checks required to process the data enrichment payload and enrich the request headers.

1...
2_M.additional_activity_handler = function(event_type, ctx, details)
3 -- verify that the request is passed to the backend
4 if event_type == 'page_requested' then
5 -- pxde - contains a parsed json of the data enrichment object
6 -- pxde_verified - makes sure that this payload is trusted and signed by PerimeterX
7 local pxde = ngx.ctx.pxde
8 local pxde_verified = ngx.ctx.pxde_verified
9 if pxde and pxde_verified then
10 -- apply the data enrichment logic here
11 -- the example below will set the f_type on the request header
12 local f_type = ngx.ctx.pxde.f_type
13 ngx.req.set_header("x-px-de-f-type", f_type)
14 end
15 end
16end
17...

For more information and the available fields in the JSON, refer to the Data Enrichment documentation.

Log Enrichment

Access logs can be enriched with the HUMAN bot information by creating an NGINX variable with the proper name. To configure this variable, use the NGINX map directive in the HTTP section of your NGINX configuration file. This should be added before additional configuration files are added.

The following variables are enabled:

  • Request UUID: pxuuid
  • Request VID: pxvid
  • Risk Round Trip: pxrtt
  • Risk Score: pxscore
  • Pass Reason: pxpass
  • Block Reason: pxblock
  • Cookie Validity: pxcookiets
  • Risk Call Reason: pxcall
1....
2http {
3 map score $pxscore { default 'none'; }
4 map pass $pxpass { default 'none'; }
5 map uuid $pxuuid { default 'none'; }
6 map rtt $pxrtt { default '0'; }
7 map block $pxblock { default 'none'; }
8 map vid $pxvid { default 'none'; }
9 map cookiets $pxcookiets { default 'none'; }
10 map px_call $pxcall { default 'none'; }
11
12 log_format enriched '$remote_addr - $remote_user [$time_local] '
13 '"$request" $status $body_bytes_sent '
14 '"$http_referer" "$http_user_agent" '
15 '| perimeterx uuid[$pxuuid] vid[$pxvid] '
16 'score[$pxscore] rtt[$pxrtt] block[$pxblock] '
17 'pass[$pxpass] cookie_ts[$pxcookiets] risk_call[$pxcall]';
18
19 access_log /var/log/nginx/access_log enriched;
20 }
21 ...