Challenge & JS Challenge

#1

When I enable challenge for a ip, I would expect that after the challenge was successfully concluded, the ip was given access.

I have an application composed by api & FE (API + Angular)

When I challenge an IP and user concludes the challenge, he has access to the front-end, but the rest api comes with empty response (error)

Any way to fix this?

#2

That should be the exact case. At least for the period of the challenge passage.

Would you have a URL where the described behaviour can be reproduced?

#3

The api is accessible via direct access, but error is thrown when the frontend tries to access it.

Everything comes back to normal when the ip is removed, or whitelisted.

The error is:

Access to XMLHttpRequest at ‘https://domain.com/api/xxx’ from origin ‘https://domain.com’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.

#4

Considering the origin is the same here you shouldnt get that error message. Are you sure that is the error? Can you post a screenshot of the actual error?

Also, as asked earlier, can you provide a URL where that can be reproduced?

#5

Excuse me, the error is:

Access to XMLHttpRequest at ‘api. domain.com/api/xxx’ from origin ‘domain.com’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.

Unfortunately I cannot disclose the real url, but the situation is that apparently while the zoe is in mode challenge, the cloudflare is turning the CORS wildcard api application, to a restricted, and the front-end is unable to fetch data even after completing the challenge.

#6

api.domain.com and domain.com are two different origins from a browser perspective and hence the error. That is not really a Cloudflare issue but you’d probably have to set the correct value for the mentioned header, after which the request should probably pass the origin check.

For follow-up questions I’d recommend to check out StackExchange and the like.

#7

so why do you explain that for all non-triggered ips, the error does not occur?

If it was not a Cloudflare related issue, I assume that it would happen everytime, and not only when the ip is triggered.

Additionally the CORS is set to wildcard:

Rails.application.config.middleware.use Rack::Cors do
  allow do
    origins '*'
    resource '*',
      :headers => :any,
      :expose  => ['access-token', 'expiry', 'token-type', 'uid', 'client'],
      :methods => [:get, :post, :options, :delete, :put]
  end
end
#8

I am not sure what you mean by “non-triggered ips”. The error message is quite clear and is a standard message in such cases and is not Cloudflare related, please search for that error message for follow-up questions. It is a CORS issue, not a Cloudflare one.

If you post the actual URL, it would be possible to analyse that further. Without the URL there is nothing to test.

#9

I found out the problem is in fact related with cloudflare, however still couldn’t find a solution.

What is happening is that after the user performs the challenge (javascript or regular), the session on that specific browser becomes whitelisted. HOWEVER, if the request is made on the firefox, or even postman, this is the begining of the output we already are familiar, and don’t belong to my api…:

<!DOCTYPE html>
<!--[if lt IE 7]> <html class="no-js ie6 oldie" lang="en-US"> <![endif]-->
<!--[if IE 7]>    <html class="no-js ie7 oldie" lang="en-US"> <![endif]-->
<!--[if IE 8]>    <html class="no-js ie8 oldie" lang="en-US"> <![endif]-->
<!--[if gt IE 8]><!-->
<html class="no-js" lang="en-US">
<!--<![endif]-->

<head>
	<title>Attention Required! | Cloudflare</title>
	<meta name="captcha-bypass" id="captcha-bypass" />

So what is happening is that I am manually blacklisting IPs, but then user blacklisted can only whitelist the session, instead of the whole ip, and this is what is causing me the issue…

#10

That is not related to Cloudflare however, but you described the standard workflow. When you pass a challenge that - naturally - only applies to the current session. If you then send out-of-band requests via different channels, they will certainly be challenged too.

You’d need to rethink your approach in this case, maybe implement authentication on your server-side and drop the challenges.

#11

I understand now how it works and it makes sense for the most common usages.

however I would like to suggest having another type of rules, where user would automatically remove the tagged ip / rule, after just completing the challenge, it would work on this situation for me.