Skip to content

Transitioning from VIP_Request_Block to IP and User Agent Restrictions in the VIP Dashboard

The VIP_Request_Block utility class provides a programmatic way to block unwanted requests at the application level based on IP addresses, user agent strings, and other parameters using PHP. Requests blocked in this manner are blocked at the origin, not the edge (load balancer). If a request is served from the cache at the edge, it does not reach the origin and cannot be blocked by this class.

However, the User Agent Restrictions and IP Restrictions features in the VIP Dashboard manage request access at the edge level before they hit the origin server. Requests blocked at the edge are handled quicker and reduce the overall load on your application as they don’t require code execution on the application. As such, using these VIP Dashboard features is the preferred method of blocking requests.

This guide details the steps required to migrate from using VIP_Request_Block in code to configuring these same restrictions in the VIP Dashboard.

Prerequisites

To update the IP or User Agent Restrictions in the dashboard, a user must have at minimum an Org admin role or an App admin role for that application.

To remove the previous restrictions from the vip-config.php, a user must have write access to the application’s GitHub Repository or codebase deployment system if using Custom Deployments.

Step 1: Identify Existing VIP_Request_Block Implementations

To transition away from using the VIP_Request_Block class, it is important to find and document all of the areas in which this class is used in vip-config/vip-config.php or included files. Information regarding which IP addresses and user agent strings are currently blocked will be required to configure restriction rules in the VIP Dashboard.

Note: This step is about identifying where this class is being used. Changes to this file should not be made until these new restrictions have been configured in the VIP Dashboard to prevent a gap in security.

  1. Open vip-config/vip-config.php or included files.
  2. Identify any instances where VIP_Request_Block is used for restricting requests based on IP addresses or user agent strings.

IP restrictions may look like:

// Example VIP_Request_Block::ip( string $value );
if ( class_exists( 'VIP_Request_Block' ) ) {
   VIP_Request_Block::ip( '13.37.13.37' );
   VIP_Request_Block::ip( '13.37.13.38' );
}

User agent restrictions matching an exact user agent string may look like:

// Example VIP_Request_Block::ua( string $user_agent );
if ( class_exists( 'VIP_Request_Block' ) ) {
   VIP_Request_Block::ua( 'SuspiciousBot/1.1' );
   VIP_Request_Block::ua( 'AnotherBot/2.1' );
}

User agent restrictions matching a partial user agent string may look like:

// Example VIP_Request_Block::ua_partial_match( string $user_agent_substring );
// Will match and block for:
// 	- SuspiciousBot/1.1
// 	- SomewhatSuspiciousBot/1.8 - https://example.com/robot-policy
if ( class_exists( 'VIP_Request_Block' ) ) {
   VIP_Request_Block::ua_partial_match( 'SuspiciousBot/' );
}

For more examples of how restrictions using VIP_Request_Block may look, please review our documentation on blocking unwanted requests to a site.

  1. Document the blocked IP Addresses and user agents as this list will be needed in the next couple of steps.

Step 2: Plan Your Request Restriction Strategy

As it is possible to combine user agent restrictions, IP restrictions, and other methods of controlling requests, careful consideration must be given to where these restrictions meet to make sure that requests that need to be blocked are blocked while not restricting access to requests that should be allowed access.

Here are a few items worth thinking about:

  • User agent restrictions are particularly useful for requests from a specific service that identifies itself, but where a specific list of IP addresses are not known.
  • IP restrictions can be in the form of an allow list, allowing only a certain set of IP addresses access to an application, or a deny list, denying access to an application based on a specified list of IP addresses.
  • CIDR IP address notations are supported by IP Restrictions, providing more flexibility in defining IP ranges.

Because of the number of options, it is important to consider how these rules overlap and intersect with one another before implementing request restrictions in the VIP Dashboard.

Step 3: Configure Request Restrictions in the VIP Dashboard

Before removing the current VIP_Request_Block implementations it is important that new access restrictions are configured in the VIP Dashboard to prevent unwanted requests from reaching the application during this transition.

Configure IP Address Restrictions

  1. Navigate to the VIP Dashboard.
  2. Select an environment from the environment dropdown located at the top of the VIP Dashboard navigation menu of the VIP Dashboard to which these restrictions will apply.
  3. Select “Security Controls” from the sidebar navigation at the left of the screen.
  4. Select “IP Restrictions” from the submenu.
  5. At the top of the page, choose either the default IP Deny List or the IP Allow List to select your IP restriction method.
  6. Select + Add. This will bring up a dialog that requests a list of IP Addresses or IP Address Ranges to add, along with an optional note for additional context.
  7. Enter the IP Addresses that you collected in your list from Step 1.
  8. Select Save. Changes may take up to 5-10 minutes to propagate.

For more detailed instructions, please refer to our documentation on the IP Restrictions panel of the VIP Dashboard.

Configure User Agent Restrictions

  1. Navigate to the VIP Dashboard.
  2. Select an environment from the environment dropdown located at the top of the VIP Dashboard navigation menu to which these restrictions will apply.
  3. Select “Security Controls” from the sidebar navigation at the left of the screen.
  4. Select “User Agent” from the submenu.
  5. Select + Add. This will bring up a dialog that requests a list of user agent strings to block.
  6. Select Equals or Contains as the restriction type. Equals looks for an exact match of the user agent string to restrict while Contains will restrict any request where the user agent string contains the supplied identifier.
  7. Enter the user agent string to be blocked.
  8. Add an optional note for reference.

Select Save.

For more detailed instructions, please refer to our documentation on the User Agent Restrictions panel of the VIP Dashboard.

Step 4: Validate the New Configuration

It is important to validate that requests are successfully being blocked by the newly configured restrictions in the VIP Dashboard before removing the existing VIP_Request_Block Implementations to make sure the application remains secure.

Validating IP Restrictions

  1. Attempt to access the site from an allowed IP and confirm that the site successfully loads.
  2. Attempt to access the site from a blocked IP. This request should return a 403 status response that does not contain caching-related headers like x-cache.

Validating User Agent Restrictions

  1. Attempt to access the site using a blocked user agent by opening a terminal window on your machine and running a command similar to this:
curl -A "BadBot" https://<environment-domain>/ -I
  1. Ensure that blocked requests are being blocked by the VIP Edge by making sure the response of the curl command does not contain caching-related headers like x-cache.

If validation fails for either of these steps, please verify that your configuration is correct. Remember that it will take 5-10 minutes after saving for the new configuration to take effect. 

If you’re unable to verify that the configuration is correct, please contact Support before removing the VIP_Request_Block code.

Step 5: Remove VIP_Request_Block Implementations

Now that the new configuration is validated to be working, it is safe to remove the existing VIP_Request_Block implementations from vip-config.php or included files.

  1. Remove or comment out all VIP_Request_Block IP address or user agent rules.
  2. Deploy the updated configuration.

Last updated: March 06, 2025