Web source verification

Web integrations 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:

Before switching to production, remove unused test domains and regularly review the allowlist so test origins do not remain in the production configuration.

Why is rate limiting configured on the integration?

Geelab places source filtering, application signature verification, and request rate limiting in the integration settings. This lets you control traffic separately for different platforms, domain names, or integration points without letting the rules for one integration point affect others 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 integrations to modify the configuration.

Web integrations use Allowed Origins and Allowed Referers to configure the source whitelist; iOS and Android integrations use information such as Bundle ID, Package Name, and App Signature to verify the origin of mobile applications. The rules for different integrations are independent of one another.

Subsequent versions may add more client-side filtering conditions and rule types, such as identifying IP addresses, search engine crawlers, or AI crawlers, as well as more flexible blacklist and rule-combination configurations. The specific capabilities will be documented when they become generally available. For now, complete the integration using the existing whitelist and signature-verification features.

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 integrations.
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.