Advanced Customization

This page covers advanced customization options that require modifying the iRule code or configuring conditional module behavior.

Enable Module Header

This configuration enables the module only when a specific header is present and its value is set to True. This is useful for gradually rolling out the enforcer or enabling it only for specific traffic.

If enable_module_header_name configuration is empty, then the enable_module configuration will determine if the module is enabled or not.

Configuration

Set the header name in the pxconfig data group:

$
modify /ltm data-group internal pxconfig records modify { enable_module_header_name { data X-PX-ENABLE-MODULE } }

When configured, the HUMAN module will only process requests that include the header X-PX-ENABLE-MODULE: True.

Use Cases

• Gradual rollout: Configure your load balancer or CDN to add the header to a percentage of traffic
• Testing: Enable the module only for requests from specific sources
• Conditional protection: Enable protection only for requests routed through a specific path

Enrich Custom Parameters

The px_add_custom_parameters function in the iRule allows you to add up to 10 custom parameters to be sent to HUMAN servers on risk_api calls. When configured, the function is called before setting the payload on every risk_api request to HUMAN servers.

Configuration

Locate the px_add_custom_parameters procedure in the px.tcl iRule and add your custom logic:

1
proc px_add_custom_parameters {} {
2
  # Custom function to add custom parameters to risk_api and async activities.
3
  set custom_parameters [list]
4
  
5
  # INSERT LOGIC HERE
6
  # Example: Add user ID from a custom header
7
  lappend custom_parameters "x-px-custom-param1" "UID"
8
  lappend custom_parameters "x-px-custom-param3" "SessionID"
9
10
  # The function must always return the custom_parameters list.
11
  return $custom_parameters
12
}

Parameter Naming

The parameters should be passed in the correct order matching your HUMAN Console configuration:

• If userid is set to custom-param1 in the HUMAN Console, it should always be sent as x-px-custom-param1
• Parameter keys must follow the pattern x-px-custom-param<number> where number is 1-10

The header key is validated before being sent to ensure the correct pattern is used.

Custom IP Extraction

The px_extract_ip procedure in the iRule can be customized to extract the client IP address from custom headers or apply custom logic.

Default Behavior

By default, the enforcer uses the ip_header configuration to determine which header contains the real client IP. If ip_header is not set, the socket IP is used.

Custom Implementation

If you need more complex IP extraction logic (e.g., parsing X-Forwarded-For with multiple IPs), you can modify the px_extract_ip procedure:

1
proc px_extract_ip {ip_header} {
2
  # Custom IP extraction logic
3
  # Example: Get the first IP from X-Forwarded-For
4
  set xff [HTTP::header value "X-Forwarded-For"]
5
  if { $xff ne "" } {
6
    # Split by comma and get the first IP
7
    set ips [split $xff ","]
8
    return [string trim [lindex $ips 0]]
9
  }
10
  # Fallback to socket IP
11
  return [IP::client_addr]
12
}

URI Delimiters

HUMAN processes URI paths with general- and sub-delimiters according to RFC 3986:

• General delimiters (e.g., ?, #) are used to separate parts of the URI
• Sub-delimiters (e.g., $, &) are not used to split the URI as they are considered valid characters in the URI path

This ensures that URIs with special characters in the path are processed correctly.