Username Availability Check Stuck During Registration

Support
1

When attempting to register on the website https://it6.cc/, the username availability check gets stuck. The message “Checking username availability…” appears and persists for an extended period, preventing normal registration from proceeding.

This is a screenshot of a web page with Chinese text. (Captioned by AI)
This is a screenshot of a web page with Chinese text. (Captioned by AI)625×697 24.2 KB

I have found the reason of problem，because of the cloudflare waf rule ,
the original rule

(cf.threat_score ge 5 and not cf.client.bot) or (not http.request.version in {"HTTP/1.2" "HTTP/2" "HTTP/3" "SPDY/3.1"}) or (not http.user_agent contains "Mozilla/")

here is the optimization rule by claude ai，this solve the problem

(cf.threat_score ge 10 and not cf.client.bot) or 
(http.request.version eq "HTTP/1.0") or 
(not http.user_agent contains "Mozilla/" and not cf.client.bot)
Explanation of Changes

Cloudflare Firewall Rule Analysis and Optimization

Current Rule:

Copy

(cf.threat_score ge 5 and not cf.client.bot) or 
(not http.request.version in {"HTTP/1.2" "HTTP/2" "HTTP/3" "SPDY/3.1"}) or 
(not http.user_agent contains "Mozilla/")

Analysis:

  1. cf.threat_score ge 5 and not cf.client.bot: This part is reasonable, blocking high-threat clients that aren’t bots.
  2. not http.request.version in {"HTTP/1.2" "HTTP/2" "HTTP/3" "SPDY/3.1"}: This might be too restrictive, potentially blocking legitimate older clients.
  3. not http.user_agent contains "Mozilla/": This could block legitimate requests from non-browser clients or API calls.

Optimized Rule:

Copy

(cf.threat_score ge 10 and not cf.client.bot) or 
(http.request.version eq "HTTP/1.0") or 
(not http.user_agent contains "Mozilla/" and not cf.client.bot)

Explanation of Changes:

  1. Increased threat score threshold to 10 to allow more legitimate traffic.
  2. Only block HTTP/1.0, allowing newer versions and SPDY.
  3. Modified user agent check to only apply to non-bot traffic, allowing API calls and legitimate non-browser clients.

Additional Considerations:

  • Add exceptions for specific paths or endpoints used for username checks:

Copy

and not (http.request.uri.path contains "/check_username")
  • Whitelist known good IP ranges or countries where most of your users are located.
  • Consider implementing rate limiting instead of outright blocking for some conditions.

Implementation:

Replace your current rule with the optimized version and monitor its effects. Adjust as needed based on your traffic patterns and security requirements.

1 Like