>

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). Business disaster recovery ensures that normal business processes at the C-end and B-end are not affected when the verification service is abnormal, ensuring business continuity. The flow chart of disaster recovery is shown below:

DisasterRecovery-1

2. Disaster Recovery Preparation

Step 1: [Preparation by GeeTest] The C-end comes with offline JS–bypass.js–GeeTest has completed logic and customer integration is not needed

Step 2: [Preparation by Customers] B-end carries out disaster recovery logic processing, and customers need to carry out exception handling on the interface of secondary validation when deploying the validate process to ensure that the business process is not blocked.

If there is an interface exception when requesting GeeTest for secondary validation or the response status is not 200, make corresponding exception handling to ensure that the business process will not be affected because of request timeout or no response of service.

Here is an example 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'}

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
Was this helpful?
Send