IP Whitelist access policies do not work as expected

[durzo]

When creating an Access Policy using IP Range whitelist, the rule is created using ALLOW, inserted before the default deny rule.

According to the cloudflare docs, ALLOW rules are still subject to One Time Pin rules unless they are set to BYPASS

Steps to reproduce:

1. create a new Access Policy
2. Use only the "Allowed IP Ranges", use your own IP for testing.
3. Apply the Access Policy to an application
4. Browse to the public hostname, you will be presented to enter your email address for OTP.

Expected results:

• Whitelisted IP is allowed through to the Service Target without any authentication from Cloudflare Zero Trust Login.

I tested the following patch locally:

diff --git a/dockflare/app/web/routes.py b/dockflare/app/web/routes.py
index adb531f..327da03 100644
--- a/dockflare/app/web/routes.py
+++ b/dockflare/app/web/routes.py
@@ -1366,7 +1366,7 @@ def _parse_and_build_policy_from_form(email_str, ip_ranges_str=None, countries_l
             allow_include_rules.append({"ip": {"ip": ip}})
 
     if allow_include_rules:
-        policies.append({"name": "Allow defined users and IPs", "decision": "allow", "include": allow_include_rules})
+        policies.append({"name": "Allow defined users and IPs", "decision": "bypass", "include": allow_include_rules})
 
 
     if countries_list:

While it worked for IP Whitelisting, it completely broke "Allowed Emails or Domains" because they are processed in the same code function but the CloudFlare API does not accept bypass for email addresses.
I believe the code needs refactoring to handle IP Whitelisting separately to Emails/Domains - 1 rule for IP, 1 rule for Email etc

[ChrispyBacon-dev]

thank you thats another good finding. this can be tricky indeed! I look into it

[ChrispyBacon-dev]

With the latest hotfix this issue and rule creation is now fixed.