Web source verification

Web endpoints use Allowed Origins and Allowed Referers to limit which websites can initiate identification requests, reducing the risk of the Public API Key being stolen by other websites.

Allowed Origins

Origin usually consists of protocol, domain name and port, and does not include the page path.

Valid example:

https://www.example.com
https://checkout.example.com
https://staging.example.com:8443

Please note:

• http:// and https:// are different origins.
• Different subdomain names usually need to be configured separately.
• Non-standard ports require the port to be written out explicitly.
• It is recommended to use HTTPS in the official environment.
• Do not add wildcard domain names that are too broad for convenience.

Allowed Referers

Referer rules can further restrict specific pages or paths. Example:

https://checkout.example.com/*
https://*.example.com/pay/*

The supported range of wildcards is subject to the console field prompts. Do not enter example.com without a protocol, and do not add uncontrolled third-party domains to the allowlist.

Configuration suggestions

It is recommended to distinguish sources by environment:

Delete test domain names that are no longer used before going online, and check the whitelist regularly to avoid long-term exposure of test sources to production configurations.

Illustration: Web source verification

Why is flow control configured on the endpoint?

Geelab places source filtering, application signature verification and request flow limiting in the endpoints settings. In this way, you can control traffic separately for different platforms, domain names or business portals, without letting the rules of one portal accidentally affect other portals under the same application.

The current version of source filtering adopts a whitelist method: only requests that pass the source or signature verification you configure will continue to be identified. The console currently does not provide an independent global traffic filtering page, nor does it provide a blacklist mode. When you need to adjust the filtering range, please enter the corresponding endpoints to modify the configuration.

The web endpoints uses Allowed Origins and Allowed Referers to configure the source whitelist; the iOS and Android endpoints use information such as Bundle ID, Package Name, and App Signature to verify the origin of mobile applications. The rules for different endpoints are independent of each other.

Subsequent versions may continue to expand more filtering conditions and rule methods on the access side, such as identifying IPs, search robots or AI robots, or provide more flexible blacklists and combination rule configurations. The specific capabilities are subject to the product description after it goes online. Currently, please complete the access according to the existing whitelist and signature verification.

Troubleshooting methods for verification failure

If the web request is denied:

1. Check the Origin actually sent by the browser.
2. Check whether the protocol, domain name, subdomain name and port match exactly.
3. Verify that the page path is not filled in the Origin field incorrectly.
4. Check whether the Referer wildcard matches the console rules.
5. Confirm that you are using the Public API Key of the current web endpoints.
6. After modifying the configuration, reload the page and initiate a test request.

Common mistakes include:

• just fill inexample.com, the protocol header is missing.
• Whether http:// is configured when https:// is required, or vice versa.
• Ignore port differences.
• Write the path into Origin.
• Only configure the production domain name, but initiate requests from the test domain name.