Support Articles

A practical guide to preparing a web application for HackGATE. This article explains how to identify all relevant domains and subdomains, decide when separate HackGATE instances are needed, and review redirects, authentication flows, API endpoints, cookies, and asset loading to ensure the application works correctly through the HackGATE proxy.

When using OAuth2-based authentication (for example with Google, Microsoft Entra ID, Azure AD B2C, Okta, Auth0, or similar IdPs) behind HackGATE, the authentication flow may fail if the HackGATE domain is not included in the OAuth2 redirect URI whitelist.

When your application is served through HackGATE, Cloudflare may block requests if a specific Cloudflare Managed Firewall Rule is triggered. This can cause the site to fail loading, appear broken, or return a 403/1020 “Access Denied” error.

When you protect your application with HackGATE and use Cloudflare Turnstile for CAPTCHA, Turnstile must be explicitly configured to allow requests from the HackGATE hostnames (e.g. yourtenant.hackgate.net). If those hostnames are not added to Turnstile’s configuration, the CAPTCHA widget may not load and validation will fail.

If you are using Google reCAPTCHA with your application behind HackGATE, you must explicitly add your HackGATE proxy domain to the list of allowed domains in the reCAPTCHA configuration. Without that, the captcha widget will not work when accessed through HackGATE.