Disaster Recovery

1. Disaster Recovery Process

The verification process involves the interaction among customer front-end(C-end), customer back-end (B-end) and GeeTest server (G-end). The exception scenarios include exception of load request, exception of validate request and exception of load & validate.

The objective of disaster recovery is to ensure the customer-end and business-end will not be interrupted when the verification service is abnormal. The flow chart of disaster recovery is shown below.

DisasterRecovery-1

Scenario	Abnormal scenario in non-disaster recovery mode	Abnormal scenario in disaster recovery mode
Front-end exception	The load request is initialized fail, and the challenge cannot be loaded.	The load request is initialized fail, and the challenge will be passed directly.
Back-end exception	The validate request failed, value cannot be returned, and the login failed.	The validate request failed, the result is successful by default setting, and the login is not affected

2. Disaster Recovery Preparation

Multiple domain names are needed in the GeeTest Disaster Recovery processes. Here are the domain names for your reference:

Main domain names: gcaptcha4.geetest.com, static.geetest.com
Backup domain names: gcaptcha4.geevisit.com, gcaptcha4.gsensebot.com, static.geevisit.com

Note: if there are restrictions on domain names, please add the following domain names to your release list: geetest.com, geevisit.com, gsensebot.com.

Client-side deployment: GeeTest has deployed disaster recovery logic on the C-end, so you can skip this part.

Server-side deployment: server-side disaster recovery deployment requires you to handle the exception of the secondary verification API while you integrate it on the server side. The reason is to ensure business will not be interrupted when the client side is requesting secondary verification API abnormally or the response status is not 200 (success).

Here is an example of how you could do this in Python:

try:
    res = requests.post(url, query)
    assert res.status_code == 200
    gt_msg = json.loads(res.text)
except Exception as e:
    gt_msg = {'result': 'success', 'reason': 'request geetest api fail'}

C#
https://github.com/GeeTeam/gt4_csharp_aspnetcoremvc_demo/blob/main/Controllers/IndexController.cs#L60
Java
https://github.com/GeeTeam/gt4-java-demo/blob/master/src/main/java/com/geetest/demo/controller/MainController.java#L60
Node
https://github.com/GeeTeam/gt4_node_express_demo/blob/main/routes/index.js#L65
PHP
https://github.com/GeeTeam/gt4-php-demo/blob/master/LoginController.php#L43
Python
https://github.com/GeeTeam/gt4-python-demo/blob/master/start.py#L53
Golang
https://github.com/GeeTeam/gt4_golang_demo/blob/main/main.go#L76

3. Disaster Recovery Test

After completing all the access, please conduct a comprehensive business disaster recovery test. For different scenarios, the recommended test process provided by GeeTest is as follows:

Test Scenario	Test Simulation Steps	Test Pass Identification (GeeTest downtime mode)
[C-end is normal, B-end is abnormal] assumes that the client can perform verification interaction at the front end, but when the customer’s server performs secondary validation, the interface exception occurs when the customer’s server requests the GeeTest service for secondary validation	1. Change the domain name that initiates secondary validation in the login interface of B end to a nonexistent address 2. Simulate the scenario that the C-end request is normal, but the interface exception occurs when B end requesting secondary validation.	1. The captcha pops up normally at the front end 2. Login button, the login is successful
[C-end is abnormal, B-end is normal] assumes that exception occurs when the C-end user requests GeeTest, the front end cannot initialize the verification, but the interaction between customer’s server and GeeTest is normal	1. Change the requested domain name of C-end initialized captcha code to a nonexistent address 2. Simulate the scenario that the C-end request is abnormal, but the B-end request is normal. 3. Perform GeeTest ID test online, and manually release it when the GeeTest confirms that it’s not from cybercrime market	1. Change the requested domain name of C-end initialized captcha code to a nonexistent address 2. Simulate the scenario that the C-end request is abnormal, but the B-end request is normal. 3. Perform GeeTest ID test online, and manually release it when the GeeTest confirms that it’s not from cybercrime market
[C-end is abnormal, B-end is abnormal] assumes that the GeeTest service is abnormal, and neither C-end nor B-end can request the GeeTest service	Turn off the verification service (all the GeeTest domain names are configured to have no domain names), and simulate the scenario that both the C and B ends are inaccessible after the service is down	1. The front-end onekey pass 2. Login button, and the login is successful

4. Disaster Recovery FAQ

1、What is the scenario will disaster recovery be triggered?
When client-side request (load request) and server-side (validate request) response status is not 200, the disaster recovery logic will be triggered by default.

2、Why are there some secondary verification requests return pass_token error?
For example, if the client is abnormal, NoCAPTCHA type will be loaded by default setting, the pass_token of NoCAPTCHA is generated locally. At this time, if the server-side interaction is normal, the secondary verification will be performed and the verification failure value will be returned to pass_token error, so as to prevent the hacker forging abnormal client scenarios. The real client abnormalities are mostly caused by network problems, which can be solved by self-service means such as switching/refreshing the network. In some extreme scenarios, GeeTest can enable traffic release to ensure business continuity.