Need explanations between clearance tokens received from different challenge

I’m an Android developer and have been working on an Android native app, in which we sometimes should launch webView to pass the CF challenges.
There are questions we have right now:

  1. Sometimes our application goes to a CF checking loop (all the time it’s JS challenge, and all the time we successfully pass the CF receiving clearance cookie), which can be solved only by passing through the CAPTCHA. Even in the logs, we don’t see JS challenge-related data. Could you please explain how it’s possible? Is it possible that the clearance token received from one type of challenge is not valid for another challenge/CF?
  2. We have two accounts for CF: one is a free account (for tests during the development), second is a billable one (for a live environment). The billable account has bot management enabled. Is it possible that the bot make difference for question 1?
  3. For some reason CF failed mainly for several regions: Japan and Brasil. Could you please explain to me is only the clearance token needed to bypass the CF or something else, maybe something region-specific?

I’d recommend using Managed Challenges over JS Challenges - they’re a lot ‘smarter’ at which challenges they present to a user.

If you’re stuck in a loop even when passing the cookie, either the cookie is invalid (they’re only valid for a limited amount of time) or it was generated by another device/domain.

My understanding is it’s tied to the domain & user (possibly by UA/IP binding).

Every plan has varying levels of anti-bot measures.

Could be bad IP reputation - if the IPs are shared or have been used as proxies, this could cause a high threat score that prompts more ‘thorough’ anti-bot measures.

Thanks for the fast answer.
I assume that right now we can’t set the Managed Challenge and replace the JS Challenge - it can affect all our other services.

Well, yes, I know that clearance token depends on UA and IP.
In our mobile app, we are using UA getting from the embedded webView settings (which means it’s different for different devices and OS-s). IP address during that moment is stable as well as nobody else using the app.

I know that clearance cookie has an expiration time, but I meant the loop in a certain short period. I don’t think it’s expired. But for JS challenges I event don’t see the logs in the Kibana board, which is from my perspective an odd behaviour.

It seems there is no answer to question 1.
Could you please tell me do you have an info about it?

Some more context:

We are developing a native Android application, which relies on a Cloudflare protected API for DDoS mitigation. Right now we are using a static UA to bypass the challenges, but this is not good enough, because the attackers are extracting the UA from the application to bypass Cloudflare challenges.
Since there exists no official native library for handling Cloudflare challenges, we decided to start working on our own. Our solution relies on Android’s web views for solving the challenges and to receive the clearance cookie. The application then sends requests to the API by including the clearance cookie and UA as part of request headers. Both the web view is used and the API requests are sent from the same device and on the same domain.
We have done a lot of testing and found the solution to work in most cases. However, sometimes, in some regions, even though the web view passes the challenge flow successfully and receives a clearance cookie, the cookie is deemed invalid for API requests. Inside the web view, the clearance works just fine, the page loads up as expected and can be reloaded without having to go through the challenge again. This issue does not just happen inside the application. When the API is requested using curl, supplied with the same cookie and UA, the cookie is still deemed invalid.

The first question mentions a CF checking loop. This happens due to the requests to API being declined by CF check, then the web view is opened to perform a challenge, then repeat the API request with the clearance, getting declined again, then again web view… and so on. We have now managed to reproduce this loop on the free account and no longer suspect bot management to be the root of problems here, at least not solely.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.