To ensure the EdgeOne client attestation SDK runs steadily in your application, refer to the following KPIs to determine whether integration is successful (recommend troubleshooting sequentially):
Verification Item 1: Client Access to EdgeOne Edge Service
Client attestation requires your client to access the EdgeOne service. If your business uses multiple CDN service providers, only the EdgeOne service provision partially supports client attestation.
Ensure the response you received includes the EO-LOG-UUID header. If this header is not included in the response, the client may have accessed services other than EdgeOne.
Verification Item 2: SDK Loaded Successfully
The SDK must be successfully loaded to complete the client attestation process.
After the SDK is successfully loaded, it will access the /.eo-sec-bot/ service in the business domain for initialization. If this request is not observed, the SDK may have an initialization exception.
Verification Item 3: Completing Client Attestation Rule Configuration
The client attestation rule defines the specific attestation requirements of the business service for clients. You need to complete configuring the client attestation rule before performing the automated attestation process. After the client attestation rule is configured correctly, when a client attempts to directly access a protected API without carrying out any attestation process, it will receive an HTTP 428 challenge response. This response will carry the EO-Attest-Challenge header.
Note:
When no client attestation rule is configured, you can still manually initiate the attestation process by calling the attestWithParams() API on the client. However, since the server API is unprotected, EdgeOne will not validate attestation credentials or respond to the HTTP 428 challenge.
If the client does not receive an HTTP 428 challenge, refer to the following process to troubleshoot below.
1. Whether the client's API request accesses the correct domain name
Whether the domain accessed by client has been parsing to EdgeOne's access via CNAME and has normal access to EdgeOne edge nodes.
2. Whether the client request is intercepted by other security policies
If the client receives interception status codes such as HTTP 567, record the EO-LOG-UUID header content in the response, and use the request ID as a filter condition in Web security analysis to confirm the specific interception reason.
3. Whether the client's API request correctly matches the client attestation rule
First, confirm which Web protection policy is used for the accessed domain name (site-level policy, domain-level policy, or policy template). On the Web protection configuration page of the site, select the corresponding policy and perform further configuration check.
Then, check whether rules are configured and enabled in Bot Management > Client Attestation. The match condition of the rules should include the request scope of the API, and the policy settings should cover the corresponding client type.
Verification Item 4: Correctly Handle HTTP 428 Challenge
The client must correctly handle challenge responses to perform adaptive attestation, renewal, and other processes.
When the client receives the HTTP 428 challenge response, it will perform the attestation process, then initiate request again.
Note:
If your client attestation rule configuration uses multiple attestation methods for an API resource (such as configuring multiple rules to protect an API resource or using SDK challenges for secondary attestation), your client will receive multiple HTTP 428 requests. Ensure your client re-initiates the request after processing each challenge.
Verification Item 5: Rendering of Interactive Attestation (Selectable)
If your application uses interactive attestation (such as interactive CAPTCHA), please ensure its UI renders correctly and responds to user actions.
Trigger the attestation process and verify the rendering position of interactive attestation. After attestation is completed, confirm the operation process is done.