> This page is for Applications Protection.

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.humansecurity.com/llms.txt.

# 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:

```bash
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.

> **Note**
>
> This customization requires editing the `px.tcl` iRule code directly.

### Configuration

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

```tcl
proc px_add_custom_parameters {} {
  # Custom function to add custom parameters to risk_api and async activities.
  set custom_parameters [list]
  
  # INSERT LOGIC HERE
  # Example: Add user ID from a custom header
  lappend custom_parameters "x-px-custom-param1" "UID"
  lappend custom_parameters "x-px-custom-param3" "SessionID"

  # The function must always return the custom_parameters list.
  return $custom_parameters
}
```

### 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.

> **Note**
>
> This customization requires editing the `px.tcl` iRule code directly.

### 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:

```tcl
proc px_extract_ip {ip_header} {
  # Custom IP extraction logic
  # Example: Get the first IP from X-Forwarded-For
  set xff [HTTP::header value "X-Forwarded-For"]
  if { $xff ne "" } {
    # Split by comma and get the first IP
    set ips [split $xff ","]
    return [string trim [lindex $ips 0]]
  }
  # Fallback to socket IP
  return [IP::client_addr]
}
```

## 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.