To get started with Real-time protection integration, you should have completed the integration in Monitor mode and received the initial traffic report from the ShieldSquare Service.
Note: Before getting started with the Real-time protection, make sure that you have gone through the configurations to be done in Monitor Mode.
Integration in Real-time protection prevents bots in real-time. In this mode, every API call is responded to with an appropriate response code that indicates the action to be taken on the incoming request.
Note: All the API calls made in this mode will be synchronous.
Follow these steps for integration in Real-time Protection.
Move to Active mode
Set your configuration file
Configure the Rules
Modify your code while moving from Monitor mode to Real-Time protection
Move the changes to your Production Environment
Block Page as an add on to ShieldSquare services
Move to Active Mode
In order to monitor your site’s traffic and control it in real-time, you need to first switch to active mode from Monitor mode. Follow the instructions below:
Assuming you have already integrated in Monitor mode, use the Sandbox ID to verify the Active mode changes and change to your Production ID once this is verified and moved to production. You can use the Sandbox ID to verify the Active mode changes first and then make use of the Production ID once the verification is done.
Set the mode of the operation depending on the mode of activation: _mode = ‘Active’; //For Active Mode
Configuring the Rules
This section helps you configure rules to manage traffic. To do so, navigate to Bot Response List under Configuration in the dashboard. The rules can be configured to return response codes as explained below:
This indicates that the request has not reached ShieldSquare due to some issues. Such requests should be allowed access.
This indicates that the request is either coming from a genuine user or a good crawler like Google or Bing, and the request should be allowed.
Indicates that the requests are coming from bad bots and a CAPTCHA page needs to be displayed.
This indicates that requests are coming from bad bots and should be blocked.
Feed Fake Data (FFD)
This indicates that requests are coming from bad bots and that you can feed fake data.
Modify your code while moving from Monitor Mode to Real-Time protection
The next step is to make a few modifications in the code that makes the API call to ShieldSquare Service. This step assumes that you have already integrated API Call in Monitor mode.
There will be no change in the JS code when switching modes.
The API call shieldsquare_ValidateRequest(username, calltype) will take the following parameters as inputs:
UserName: Set the User ID of the logged-in visitors to shieldsquare_username
CallType: The value of shieldsquare_calltype determines the type of the call and can have the values below:
If the current request is for a page load, pass the call type parameter to the service as 1
If the current request is a Form Submit, pass the call type parameter to the service as 2
If the current page is a CAPTCHA page or Block page, pass the call type parameter to the service as 4
If the CAPTCHA is solved successfully, pass the call type parameter to the service as 5
If the current request is from a mobile app, pass the call type parameter to the service as 6
If the current request is from a feature phone, pass the call type parameter to the service as 7
Keep this parameter as an empty string for all call types.
@shieldsquare_call_type ||= 1 // Update corresponding value as per CallType in the below table.
@shieldsquare_response = Ss2.shieldsquare_ValidateRequest("shield_square_user_name", @shieldsquare_call_type, "", request, cookies)
if @shieldsquare_response.responsecode == 0
logger.debug "Allow the user request"
elsif @shieldsquare_response.responsecode == 2
logger.debug "Show CAPTCHA to the user"
elsif @shieldsquare_response.responsecode == 3
logger.debug "Block This request"
elsif @shieldsquare_response.responsecode == 4
logger.debug "Feed Fake Data"
elsif @shieldsquare_response.responsecode == -1
logger.debug "Please reach out to ShieldSquare support team for assistance "
logger.debug "Allow the user request"
redirect_url = @shieldsquare_response.url
redirect_to(redirect_url) and return
The response from the API will be a JSON response. The response code can be retrieved as the value of the “responsecode” field of the JSON response and is of the type integer. These will have values that you have configured in the previous step.
Visit the verify integration page in the ShieldSquare Admin Portal. Green checkmarks for "API Data - IP Details" & "API Data - Session Details" will indicate the successful integration of ShieldSquare with your website. A minimum of 5 requests has to be made from the same machine using the same browser for the checkmarks to appear as an indication of the status of integration. A red checkmark indicates that a particular step might have been executed incorrectly.
The verification will only be successful when the Sandbox ID is assigned in the ss2_config.rb file. Post successful verification. We strongly recommended that you share the ss2_config.rb file with ShieldSquare Support.
The ShieldSquare Customer Onboarding team will verify and validate the configurations typically within 24 hours. This will ensure that the production site’s performance is not affected due to a wrong configuration set during the integration process.
In order to move changes to production, replace_sidparameter ( in the ss2_config file) with the Production ID. It takes about 2-3 hours for the production data to reflect in the ShieldSquare Dashboard.
Note: The ShieldSquare Dashboard will not populate data if the Sandbox ID is used.