Rules for allowing Invisioncommunity API?

What is the name of the domain?

vpuniverse.com

What is the issue you’re encountering

The security settings are already set to “Essentially Off”. What do I need to set to allow these URI?

What steps have you taken to resolve the issue?

I’m running the InvisionCommunity CMS on my site. The server uses ngnix, but the CMS normally uses Apache. There is an .htaccess file that needed to be added, but ngnix does not use .htaccess. We converted the .htaccess to ngnix config and it does work. If I completely disable Cloudflare the API works fine. However, when Cloudflare is enabled the API does NOT work. Evidently there is something within Cloudflare that is blocking this from working.

My server admins have been trying to assist. How would I go about doing this?

About the API, we can see once we access the vpuniverse.com/api through a browser, the page requests an API token, but through a command line (curl), it stops on the Cloudflare verification page (JS Challenge). You may need to check on your Cloudflare account to configure it to don’t check/send JS challenges to /api requests… you can try to create a custom rule, where the URI is api and the action is set to “Ignore”, so there shouldn’t be a JS Challenge when connecting to your API from a command line/API endpoints.

This is the response when running curl on your api website:

root@host:~# curl https://vpuniverse.com/api

Just a moment...

root@host:~# curl -I https://vpuniverse.com/api
HTTP/2 403
date: Tue, 17 Sep 2024 19:19:31 GMT
content-type: text/html; charset=UTF-8
content-length: 16819

I’ve tried creating a rule (screenshot attached), but I don’t see an option to “Ignore”. The security settings are already set to “Essentially Off”. What do I need to set to allow these URI?

Screenshot of the error

I was just thinking… Could there be something within Cloudflare blocking the ngnix config?

This is what was added to the ngnix config.

location /api/ {
if (!-e $request_filename){
rewrite ^/api/(.*)$ /api/index.php;
}
}

I would do two things:

  1. Run Trace on your affected URL and make sure to specify curl’s User-Agent in the relevant field when doing so. Trace will output all the rules that are matching on your request right now and should help you narrow down what is causing this issue.
  2. Then, search Security Events for all requests to that URL. This should output the exact rule (managed or custom) that caused this back in time. If that rule is still enabled, you can either disable it or skip it.

Security Level is primarily an IP-based feature and it won’t help here.

Thank you. That helps a bit. Seems to be getting a “managed_challenge”. From what I can tell this is coming from Super Bot Fight Mode for automated traffic. The API is automated traffic, so I don’t need traffic from the API to be mitigated.

Trace seems to be returning the following:
{
“step_name”: “06859313061044198d5894aa11547ce8”,
“type”: “rule”,
“matched”: true,
“action_parameter”: {
“id”: “48ba18287c544bd7bdbe842a294f1ae2”,
“version”: “latest”,
“overrides”: {
“rules”: [
{
“id”: “874a3e315c344b1281ad4f00046aab6f”,
“action”: “managed_challenge”,
“enabled”: true
},
{
“id”: “5ac94856e22545c0ac580ded156bc052”,
“action”: “managed_challenge”,
“enabled”: true
}
]
}
},
“expression”: “true”,
“action”: “execute”
}

Under Bots - Configure Super Bot Fight Mode - If I set “Definitely automated” to Allowed. It works, but I don’t think that is something that I want to do, right? I want to not allow automated traffic unless from/to the API.

No, you definitely don’t want to allow all automated traffic. Instead, I’d suggest configuring a skip rule targeting All Super Bot Fight Mode rules for specific requests that you want to let through (i.e. your source IP, HTTP header, user-agent, etc).