SDK Integration | Ruby - Active mode

Getting Started

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.


Real-time Protection

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

  • Verify Integration

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

  1. Login to your dashboard

  2. Click on Bot Response List

  3. Switch the toggle button present on the right side of the screen from Monitor to Active

  4. Change the value of the _mode property in the config file to "Active" instead of "Monitor"

Set your Configuration file

The configuration file which was set during monitor mode integration will now need a few changes. These changes attribute to switching from Monitor to Active mode.

The final ss2_config.rb should look like (values may differ):

1 2 3 4 5 6 7 8 9 config.sid = “Your Production ID” config.mode = "Active" config.async_http_post = true config.timeout_value = 100 config._ipaddr = "auto" config.ss2_domain = '' config.domain_ttl = 3600 config.domain_cache_file = '/tmp/' config.deployment_number = '1234'

 Parameters which will need changes.










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

Page ID

Keep this parameter as an empty string for all call types.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 def call_shield_square @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" end redirect_url = @shieldsquare_response.url unless redirect_url.blank? redirect_to(redirect_url) and return end end

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.

Verify Integration

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.

Move Changes to Production

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 config.sid =“YourProduction ID” config.mode ="Active" config.async_http_post =true config.timeout_value =100 config._ipaddr ="auto" config.ss2_domain ='' config.domain_ttl =3600 config.domain_cache_file ='/tmp/' config.deployment_number ='1234' config.ip_index = 1 config._support_email = "" config._redirect_domain = "" config._ss_block_enabled = true config._ss_captcha_enabled = true config._sessid = ""

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.