I would like to request an enhancement to the current reCAPTCHA implementation. At the moment, enabling reCAPTCHA enforcement applies the validation requirement globally to all routes under a given domain. This creates operational issues for systems that rely on machine‑to‑machine communication, particularly API endpoints that cannot complete interactive CAPTCHA challenges.
Proposed Improvement
Introduce support for path‑level exemptions within the reCAPTCHA configuration. This would allow administrators to enable reCAPTCHA protection for the main website while explicitly excluding specific routes (e.g., /api/*) from validation. Such a mechanism could be implemented through:
- A list of regex or prefix‑based path exceptions
- Per‑route reCAPTCHA toggles within the routing rules
- A rule‑based engine that evaluates reCAPTCHA requirements before request forwarding
Rationale
Modern applications frequently separate frontend and backend concerns, with the frontend protected by human‑verification mechanisms while backend services communicate programmatically. Without the ability to define exceptions, enabling reCAPTCHA can unintentionally break internal API calls, webhooks, mobile apps, and other automated integrations.
Adding path‑level exemptions would significantly increase deployment flexibility and align Zoraxy with common reverse‑proxy and WAF patterns used in production environments.
Thank you for your continued work on the project.
I would like to request an enhancement to the current reCAPTCHA implementation. At the moment, enabling reCAPTCHA enforcement applies the validation requirement globally to all routes under a given domain. This creates operational issues for systems that rely on machine‑to‑machine communication, particularly API endpoints that cannot complete interactive CAPTCHA challenges.
Proposed Improvement
Introduce support for path‑level exemptions within the reCAPTCHA configuration. This would allow administrators to enable reCAPTCHA protection for the main website while explicitly excluding specific routes (e.g., /api/*) from validation. Such a mechanism could be implemented through:
Rationale
Modern applications frequently separate frontend and backend concerns, with the frontend protected by human‑verification mechanisms while backend services communicate programmatically. Without the ability to define exceptions, enabling reCAPTCHA can unintentionally break internal API calls, webhooks, mobile apps, and other automated integrations.
Adding path‑level exemptions would significantly increase deployment flexibility and align Zoraxy with common reverse‑proxy and WAF patterns used in production environments.
Thank you for your continued work on the project.