This is a crisp and precise integration guide that will facilitate the integration of ShieldSquare - Real-time Bot Management Solution for Web Apps, Mobile & APIs at the application level using our Ruby on Rails SDK. Please login and download the connectors from here
Ruby version >=2.0andRails>=3
Integrating ShieldSquare in Monitor Mode
ShieldSquare integration in the monitor mode is divided into 3 simple steps
Integrate the Code
Move changes to production
Integrate the Code
On integrating the code, the SDK will start making API calls to ShieldSquare solution and the response received is in the form of a response code. The response code directly indicates the action to be taken based on the incoming request. All API calls made to ShieldSquare, (in monitor mode) by default would be asynchronous in nature, based on the compatibility of the website platform. In case your website platform does not support asynchronous calls, please reach out to support for further assistance.
Please follow the below-outlined steps to integrate the code in Monitor Mode:
Note: Add the below line to the above configuration file for backward compatibility. If you are a new customer, ignore this line. config.js_url='/getData'
In order to understand the function and use of each of the parameters listed in the ss2_config.rb file, refer to the below table.
This holds the subscriber id of the user and can be obtained by clicking on the Subscriber id details link on the dashboard. Choose Sandbox Id as you are integrating for the very first time
Important Note: Sandbox ID is meant for only testing and verification purposes and requests sent using this ID will not be persisted by ShieldSquare Service.
Sets the mode of the operation depending on the mode of activation. Set value to ‘Monitor’ in this case.
This Boolean parameter is used to post the data asynchronously. In the Monitor mode, this has to be set as ‘true’.
This parameter indicates the time limit after which an API call has to be timed out. No synchronous API call would block for more than the value specified to this parameter.
Important Note: To know the optimum value to be set as timeout, run this jar file on your server and note the value. Refer to the guide for detailed steps to achieve the same.Download the ‘jar’ file.The jar may take about 15 minutes to run before it gives an output.
A numeric value (measured in milliseconds)
This is set to the HTTP header which indicates the IP address of the user. The default value is “auto”.
Quick Tip: TheRelative path of “www.example.com/ShieldSquare/getData” is “/ShieldSquare/getData”. The simplest solution to work around this complexity is to place all the connector files in the root folder and set the _js_url parameter to “/getData”.
Important Note: This parameter is only used for backward compatibility. Kindly ignore.
Select the ShieldSquare server closest to the website's server and assign it to the _ss2_domain property. Available options are:
This parameter is the path to a cache file which stores the resolved IP of the _ss2_domain. The default path is "/tmp/"
Important Note: To use this feature your application server [Apache/Nginx] should have write access to the folder specified above.
This parameter indicates the time after which _domain_cache_file is reloaded. The default time is 3600 seconds
Important Note: To disable the caching feature, set the value as -1
Numeric value (measured in seconds)
Identifier denoting different families of configuration settings in your servers
3. Integrate the API call to your code:
After making changes to the ss2_config.rb file parameters, the API code snippet needs to be added to the common header file of your website. The code snippet to be included is shown below:
@shieldsquare_call_type ||= 1 // Update corresponding value as per CallType in the above table.
@shieldsquare_response = Ss2.shieldsquare_ValidateRequest("shield_square_user_name", @shieldsquare_call_type, "", request, cookies)
if @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
Once the code is inserted, the validate request function ( highlighted in the above code) takes the userid, call type, pid as inputs to process requests. Each of the parameters of the validate request function are defined below:
Set the user-name/user-id of the logged-in visitors to shieldsquare_userid.
The value of shieldsquare_calltype determines the type of the call and can have the below values:
1 - Set the value as 1 for this parameter when the current request is of type Page Load. 2 - Set the value as 2 for this parameter when the current request is a form submit request. 6 - Set the value as 6 for this parameter when the current request is from mobile APP. 7 - Set the value as 7 for this parameter when the current request is from feature phone.
Uniquely identifies a request.
API call returns response in json format. The response code can be found as the value of “responsecode” field returned and is of the type integer.
Possible response codes are:
This indicates that the request should be allowed.This is the default response for monitor mode.
Indicates that the ShieldSquare service is facing issues . The request should be allowed in case this response code is received. For eg. this response code will be returned in case a timeout occurs.
A response code of -1 is usually received when a server timeout occurs.
Integrate the JS in the starting of head section of web pages protected by ShieldSquare to ensure JS Tag executes immediately after the page loads. This will facilitate ShieldSquare to catch sophisticated bots.
Both the aforementioned code snippets (API & JS) need to be executed from the every page of the website. It is therefore mandatory to include both the snippets in the common header file.
Visit the verify integration page in the ShieldSquare Admin Portal and green check marks for "API Data - IP Details" & "API Data - Session Details" will indicate the successful integration of ShieldSquare with your website. A minimum of 5 requests have to be made from the same machine using the same browser for the check marks to appear as an indication to the status of integration. In the event of a Red check mark, it 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, it is strongly recommended that you share the ss2_config.rb file with ShieldSquare Support
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 in the process of integration.
Move changes to Production
In order to move changes to production replace _sid parameter ( 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. Refer the below snapshot:
Note: The ShieldSquare Dashboard will not populate data if the Sandbox ID is used.
Please send an email to firstname.lastname@example.org confirming the changes moved to production. The Radware Bot Manager support team will verify the correctness of data received by the ShieldSquare servers. A dedicated data scientist will be assigned to your website to analyze site-specific bot patterns. Any fine-tuning required for bot classification rules specific to your site will be taken care of. Within 24 hours of successful replication of changes in the production, ShieldSquare Dashboard will be released, enabling exhaustive insights on bot traffic.