Upgrade to Fastly VCL v12
If you have an existing Fastly VCL Enforcer configuration, you can learn how to upgrade to v12 in this article.
Prerequisites
If you are using the Deploy Tool method, you may need:
- Depending on your preferred deployment method, the following tools:
- Docker method:
- Docker. See how to install Docker with their documentation.
- Script method:
- Node.js 20.x or later and npm 10.x or later. See how to install both with npm’s documentation.
- Git CLI. You can download it directly from Git.
- GNU Wget. See how to install with their documentation.
- Docker method:
- Any custom Fastly files you would like to deploy. These are optional, but can be used to include any custom configurations you may need. Ensure they align with the latest version. If you are using the Docker method, make sure they are saved in the
/deploy
folder. Possible files include:main.vcl
(MAIN): Ensure all thepx_*
subroutines are invoked where needed.px.vcl
(PX)px_configs.vcl
(PX_CONFIGS): Ensure it aligns with the information in theenforcerConfig.json
provided.px_custom.vcl
(PX_CUSTOM): Use the latest version and add any custom implementations as needed.
If you are upgrading manually, have the following ready, including with any custom implementations if needed:
main.vcl
(MAIN): Fastly's default main VCL with HUMAN logic already integrated. This file can be used as the main VCL file for Fastly services that don't have one, or as a basic example for how to integrate the HUMAN logic into an existing main VCL file.px.vcl
(PX): All HUMAN core logic. This file should not be customized or modified in any way. Provided by HUMAN.px_configs.vcl
(PX_CONFIGS): Contains Enforcer configuration table and additional backend configs. This file can be modified based on the desired Enforcer configuration. Provided by HUMAN.px_custom.vcl
(PX_CUSTOM): Contains Enforcer custom code, defined custom behavior, and Enforcer features. This file can be modified based on the desired Enforcer configuration or desired custom logic that should be executed within the Enforcer. Provided by HUMAN.
Upgrade with the Deploy Tool
You can use HUMAN's Deploy Tool to quickly walk through the necessary configuration changes needed to upgrade your Enforcer version. This reduces the manual work you need to complete to upgrade the Enforcer.
Warning
Be aware that if your Enforcer version is very old, then some features and configurations may not completely carry over. Especially in these cases, the best practice is to review the upgraded Fastly service thoroughly before activating it.
Download the Enforcer configuration file
The Enforcer configuration file, enforcerConfig.json
, has important information about your HUMAN account such as your Application ID or server token that the Enforcer uses to work with your application. If you don’t have one already, you need to download this file from the HUMAN console. Otherwise, move on to Create a Fastly API token.
- Navigate to Platform Settings > Configurations > Enforcers.
- Click the Enforcer that you’re currently updating.
- Click the download
button to download
enforcerConfig.json
. - Save the file in a directory that you’ll remember, such as
/deploy
.
Create a Fastly API token
If you do not have a Fastly API token yet, create one with the following steps. If you have one, move on to Run the Deploy Tool.
- Log in to your Fastly account.
- Navigate to Account > API Tokens > Personal tokens.
- Click Create token.
- Enter a name for your token, then fill out the remaining fields according to the following:
- Type: User token. Only available for Fastly Superusers. If you don't see this field, you can skip this step.
- Scope: Global API access (
global
) . Be sure to also deselect Read-only access (global:read
), which is selected by default. - Access: All services or the specific services you want to deploy the Enforcer on
- Click Create Token.
- Copy and save the token in a secure location.
Warning
This will be the only time you’ll see your token, so be sure to save it before closing the page!
Run the Deploy Tool
You can run the Deploy Tool with either of the following methods:
Docker method
Note for Windows users
Windows users also need to complete additional setup for Docker:
- In your Windows search bar, search for and open “Turn Windows features on or off”.
- Find the Windows Hypervisor Platform feature and enable it.
- Click OK to save your changes.
- Open Windows PowerShell as an Administrator.
- Copy and paste in
C:\Windows\System32\wsl.exe --update --web-download
, then hit Enter.
- Pull the Docker Image by running:
docker pull us-docker.pkg.dev/hmn-registry/docker-public/cdn-enforcer-deploy-tool
- Navigate to the directory where you created
enforcerConfig.json
. Based on our example from above, this would be the/deploy
directory. - Run the deploy tool with the following:
docker run --rm -v $PWD:/app/local -it us-docker.pkg.dev/hmn-registry/docker-public/cdn-enforcer-deploy-tool
Script method
- Navigate to the directory where you created
enforcerConfig.json
. Based on our example from above, this would be the/deploy
directory. - Pull the HUMAN Deploy Tool zip from Google Artifact Registry using:
- Unzip
cdn-enforcer-deploy-tool.zip
to the same directory you savedenforcerConfig.json
in. - Run the tool by opening the appropriate script for your system:
- Windows:
cdn-enforcer-deploy-tool.bat
- Mac or Linux:
cdn-enforcer-deploy-tool.command
- Windows:
Upgrade and deploy the Enforcer
- When prompted, select Fastly VCL and hit Enter. The Deploy Tool will detect if you have an existing Fastly Enforcer version and automatically start the process to upgrade to the latest version.
🚀 HUMAN CDN Enforcer Deploy Tool 🚀
? Which platform do you want to deploy to? (Use arrow keys)
❯ Fastly VCL
Cloudflare Workers
...
- Continue to follow the steps that appear to complete your deployment.
Note
If you have any custom VCL files that are different from the default, such as custom subroutines in PX_CUSTOM, be sure to choose to deploy custom VCL files and choose those files.
- When you finish the setup, confirm that the displayed details are correct, then enter
y
to deploy the Enforcer.
Upgrade manually
To ensure that you are taking advantage of the latest features, several configurations and deploy changes need to be made in order to upgrade your Fastly VCL Enforcer to version 12. This document serves as a comprehensive guide to the changes that must be made.
1. Add Async Activities and Telemetry logging endpoints
Note
This change is required if upgrading from version <9.x.
Instead of using a Syslog log streaming endpoint, we've changed our async activities and telemetry logs to use Fastly's HTTP logging endpoint.
This change requires removing the older PX-Syslog logging endpoint and configuring two new logging endpoints instead. For more information about Fastly log streaming, see here.
Delete the PX-Syslog Logging Endpoint
- In your Fastly service, go to "Logging" tab.
- Delete the TCP logging endpoint named PX-Syslog.
Add the Async Activities Logging Endpoint
-
On your Fastly service, go to "Logging" tab
-
Add a new Logging endpoint with the information below:
- Name: PX-Async-Activities
- URL:
https://collector-<px_app_id>.perimeterx.net/api/v1/collector/s2s
- Placement: none
- Maximum bytes: 500000
- Advanced options:
- Content type - application/json
- JSON log entry format - Array of JSON
- All other fields: No change is needed, use the default values.
Add the Telemetry Logging Endpoint
- On your Fastly service, go to "Logging" tab
- Use the following settings to define a new additional logger:
- Name: PX-Telemetry
- URL:
https://collector-<px_app_id>.perimeterx.net/api/v2/risk/telemetry
- Placement: none
- Maximum Logs: 1
- Advanced options
- Content type - application/json
- All other fields: No change is needed, use the default values.
2. Validate the px_configs configuration table in the PX_CONFIGS VCL file
Several configuration options were deprecated in Fastly VCL v10. If one or more configurations in the list below are present in the px_configs
table of the PX_CONFIGS
VCL file, please modify them accordingly.
Configuration Name | Change | Notes |
---|---|---|
px_module_mode | Configuration options have been changed. | The "async_monitor" value is no longer available. The "monitor" value should be used instead. |
px_block_all_size_exceeded_post_requests | Configuration has been removed. | POST requests with bodies larger than 8 KB will go through normal processing. |
px_block_size_exceeded_post_requests_by_size | Configuration has been removed. | POST requests with bodies larger than 8 KB will go through normal processing. |
px_enable_error_logs | Configuration has been removed. | Rather than checking this configuration, the enforcer checks if the px_logger_severity configuration is set to "error" . |
px_enable_redirect_xhr | Configuration has been removed. | First party XHR routes should be treated like all other First Party routes. Instead of XHR routes having their own individual setting, they now depend on the px_first_party_enabled configuration option. |
px_send_page_activities | Configuration has been removed. | Asynchronous activities should always be sent and should not be turned off. |
px_enable_access_control_header | Configuration has been removed. | See the changes to the px_custom_access_control_header custom subroutine. |
px_csp_enabled | Configuration has been removed. | The CSP feature has been removed. |
px_bypass_monitor_header | Configuration default value has changed. | The default value has changed from an empty string to "x-px-block" . |
px_sensitive_headers_enabled | Configuration value has been removed. | The subroutine px_custom_unset_sensitive_headers is invoked always. |
px_filter_on_cache_hit_enabled | Configuration value has been removed. | The feature has been removed. |
3. Validate the subroutines and tables in the PX_CUSTOM VCL file
To change the PX_CUSTOM file:
- Make a copy of your PX_CUSTOM VCL file on your local computer for safekeeping.
- Upload the new v12 PX_CUSTOM VCL file to your Fastly service.
- One by one, compare each custom subroutine in your old PX_CUSTOM VCL with the new subroutine. Transfer the previously existing implementation to the new PX_CUSTOM VCL file, modifying it as needed. All desired logic should remain the same (pay special attention to conditionals and regular expressions!); most if not all the changes will likely be related to header names and return values. See the table below for details about specific subroutines.
Custom Subroutine Name | Change | Notes |
---|---|---|
px_custom_check_block_post_url | Subroutine has been removed. | This subroutine was not invoked in previous versions and had no effect. |
px_custom_check_block_by_size | Subroutine has been removed. | This subroutine was not invoked in previous versions and had no effect. |
px_custom_check_enabled_route | Subroutine has been removed. | This logic can be implemented in your MAIN VCL as desired. |
px_custom_redirect | Subroutine has been removed. | This logic can be implemented in your MAIN VCL as desired. |
px_custom_data_enrichment_handler | Subroutine has been removed. | This logic can be implemented in your MAIN VCL as desired. |
px_custom_captcha_handler | Subroutine has been removed. | Use the px_custom_block_handler custom subroutine instead. |
px_custom_access_control_header | Subroutine has been removed. | Use the px_custom_cors_set_custom_block_response_headers custom subroutine instead. |
px_custom_create_block_page | Subroutine has been renamed. | The new subroutine is named px_custom_block_page_content . |
px_custom_create_synthetic_mobile_response | Subroutine has been removed. | Mobile block response structures should not be modified as this will interfere with the Mobile SDK's functionality. If this is problematic for your setup, please reach out to your HUMAN Solution Architect. |
px_custom_create_synthetic_web_response | Subroutine has been renamed. | The new subroutine is named px_custom_web_block_page_response . |
px_custom_block_handler | Subroutine has been removed. | Use the px_custom_web_block_page_response custom subroutine instead. |
px_custom_post_block_handler | Subroutine has been removed. | This subroutine was not invoked in previous versions and had no effect. |
px_custom_is_login_request | Subroutine has been changed. | This subroutine now returns a string value instead of setting the req.http.login-set header. |
px_custom_login_extraction_callback | Subroutine has been changed | The req.http.login-set header used in this subroutine has been renamed to req.http.px-creds:endpoint-index . |
px_custom_set_login_successful_response_header | Subroutine has been changed. | This subroutine now returns a string value of "0" or "1" indicating whether the login was successful instead of setting the resp.http.x-px-login-successful header. |
px_custom_extract_jwt_additional_fields | Subroutine has been changed. | This subroutine now expects a string return value in format of "fieldName1":"fieldValue1","fieldName2":"fieldValue2" (without initial { and final } required for JSON syntax) rather than setting the header req.http.px-jwt:Additional-Fields . |
px_custom_additional_activity_handler | Subroutine has been changed. | The subroutine has been moved from the px_deliver subroutine to the px_recv subroutine (after restart/cookie parsing). |
Some tables and dictionaries in the PX_CUSTOM VCL file have also changed. See the table below for details.
Table Name | Change | Notes |
---|---|---|
px_login_credentials_extraction | Table options have changed. | The use_callback key has been removed. Instead, the sent_through key can be set to "custom" to achieve the same effect. |
cs_data | Table has been removed. | The table was used previously to store the Fastly API token and the px_enforcer_config_rdata_id , which have been moved to the px_configs table instead. |
px_csp_data | Table has been removed. | The CSP feature has been removed. |
px_enforcer_config_rdata | Table has been changed to dictionary. | The table is no longer present in the PX_CUSTOM VCL file and must always be added to the Fastly service as a dictionary. |
If upgrading from 9.x and earlier
As part of an effort to reduce HUMAN's Fastly VCL workspace footprint, many custom subroutines in the PX_CUSTOM
VCL file have been changed to return boolean values instead of setting headers.
Please pay special attention to these custom subroutines:
- px_custom_check_sensitive_route
- px_custom_check_sensitive_graphql_operation
- px_custom_filter_by_http_method
- px_custom_filter_by_user_agent
- px_custom_filter_by_route
- px_custom_filter_by_extension
- px_custom_filter_by_ip
- px_custom_enforced_routes
- px_custom_monitored_routes
- px_custom_check_enabled_route
We've also adjusted px_custom_check_sensitive_route
subroutine to return a boolean value instead of setting a header. Here is the previous implementation of this subroutine:
# implementation in v9.x and below
sub px_custom_check_sensitive_route {
if (req.url.path ~ {"<sensitive_routes>"}) {
set req.http.X-PX-sensitive-route = "1";
}
}
Compare this with the newer implementation of the subroutine:
# implementation in v12
sub px_custom_check_sensitive_route BOOL {
if (req.url.path ~ {"<sensitive_routes>"}) {
return true;
}
return false;
}
The regular expression in the condition (i.e., <sensitive_routes>
) should stay the same for both implementations. The difference is that instead of setting the X-PX-sensitive-route
header, we can simply return true
.
4. Remove references to X-PX-* headers
In version 9.x and earlier, HUMAN used headers beginning with x-px-*
to store information during the duration of the Fastly request life cycle. These headers have been renamed in version 12 and will no longer be present on the request. Any references to these headers in your Fastly VCL code should be removed.
Warning
If you have logic in your Fastly VCL files that relies on these
x-px-*
headers, please reach out to your HUMAN Solution Architect or Customer Support for guidance on how to align this code with version 12.
5. Add remote configuration parameters and dictionaries
Version 12 includes the new remote configuration feature. Remote configuration is a feature that lets you access and modify your Enforcer’s configuration remotely without redeploying. This also allows the HUMAN team to troubleshoot or customize your Enforcer directly. Remote configuration is required as part of your Enforcer setup.
Note
HUMAN will never change your Enforcer configuration without your permission. You can learn more about remote configurations with our help article.
- Please refer to the instructions here for how to add the new remote configuration fields to your PX_CONFIGS VCL file.
- Please refer to the instructions here for how to add in the required dictionaries to your Fastly VCL service.
6. Add a call to px_log in the vcl_log subroutine
As part of version 12 we have moved the sending of our async activities to the px_log
subroutine, which should be called at the beginning of the vcl_log
subroutine. Please add a call to the px_log
subroutine at the beginning of the vcl_log
subroutine (see Install the Fastly VCL Enforcer v12 for an example).
Updated 24 days ago