Clover13

I got it, thanks @Ryan Ashbrook Whitelisted the server IP at: Security → WAF → Tools → IP Access Rules

What fix did you implement for the corp VPN? 🙂

But only the CF Pro account and domain would do this, not the 2 other CF Free accounts and domains?

Figured I'd ask in this forum to see if any other site owners or developers have any insight into this issue I'm experiencing on one of my sites. The setup: 1 server that hosts 3 IPS sites. All sites running the same version of IPS (latest patched). 1 site uses Cloudflare Pro, 2 sites use Cloudflare Free CF Pro site gets a warning/error in the AdminCP indicating rewriting does not seem to be working, however the FURLs do work OK. CF Pro site does not work with the AdminCP API. It loops to the same screen with Continue despite the .htaccess being in the proper /api directory. The other 2 sites using CF Free do not experience this issue. Disabling CF on the CF Pro site resolves the issues with the errors/warnings and the API screen works fine (without changing anything else). This isolates the problem to something with CF Pro however I've been through every setting and compared to the other 2 CF Free sites and cannot identify anything that would be causing this. Anyone have any ideas?

Alright, so you mentioned CF so I disabled that and low and behold it worked again. Re-enabled and after a short while, it broke again. That lead me to think it was a corrupt cache but purging the entire cache did not resolve it. The one primary difference is this one site is on a CF Pro account and the others are not. So now it's matter of what on CF changed with Pro accounts recently that influences this.

Also nothing identified in the AdminCP Support panel. Running latest version and 0 critical issues and 0 recommendations.

I reviewed the php.ini and installed php packages and versions. Both the working and non-working sites are identical. Likewise, with the .htaccess at both the root and /api levels was compared and tested. So I'm at a dead end here as to where to check. Is there not any log anywhere that would identify what is causing the error or causing the API admin page to go into an infinite loop of Continue despite the .htaccess file (downloaded from that same screen) being present in the /api directory?

Heh, and the host says their accounts for each site are identical (ala cPanel, etc), so it can only be the software. I wonder if @Thomas Hop figured it out. Any chance it could be some permissions issue? Where else can I look to try and narrow down on this problem? Any system/error logs that would identify what isn't working and causing that error?

Yes it was renamed correctly. There was also an existing one in there that worked for a long time until recently, which I subsequently renamed (.htaccess-20240415) and reuploaded a IPS ACP generated .htaccess file. Same result. Just an infinite "Continue" loop at the API menu of ACP.

I did, I removed it all down to just the IPS rules and it still resulted in the same issue. Also worth adding, the htaccess file that was working wasn't changed for years. So something changed, either at the host level or at the IPS level. I can't tell which because it's a single server with 3 instances of IPS runnings where two work and one doesn't. The FURL rewrites seem to work fine, but the API menu in the ACP keeps prompting me to install the htaccess file in the api directory (which I did) but hitting Continue does nothing but reload the initial page.

Something to add that is important, my rewrites on the "broken" site do seem to work as FURLs work. However the REST API will not, it keeps asking me to upload the htaccess file, which is there and has been there and worked before. I reuploaded it with the same result of not working. Likewise that error shows on the Rewrite URLs config setting in the Admin CP.

@Thomas Hop did you ever figure out the fix for this? I'm having a similar problem. Threes sites running on the same server and one of them has this issue while the other two don't. All running the same version of IC (latest patched). Having host review it, but am baffled at what could be different for one site vs the two others when they're running on the same server with what should be the same setup.

FWIW I didn't need to store revisions for my use case, so I turned that off and it will work as it should. If you need revisions you'll have to wait for a fix or do something custom as @teraßyte mentioned.

Possible bug. The POST does work for most of the input I'm passing, but failing under certain cases. Would prefer to PM the details as it's a specific case that is not working and I'm not really sure what is causing it, so best to provide the actual REST POST data and the subsequent query being created by the IPS software that is failing (as seen in the System Logs). Will also provide a working case for comparison.

I'm on like my 6th review now trying to figure out what they need or want to verify the app and business. I upload exactly what they require, I send messages asking for feedback, I try to send messages to their Support Chat and receive no answers. It's been denied twice and the supporting reasoning was either corrected or incorrect (as that exact information was indeed provided). The other times, the review was just cancelled with no reason (after weeks+ of waiting).

I see how you tracked it down in the PHP code, I'll try to do that next time as well. I'm not too PHP savvy, but I see the stacktrace there and how you tracked it down, thank you for doing that! 👍 Also confirming with revisions OFF for the Pages DB, it does work and returns a 201 (CREATED) 2024-03-21 11:12:21 - INFO - post_cms_record_url: http://localhost/api/index.php?/cms/records/1 2024-03-21 11:12:21 - INFO - post_data: {'category': 1, 'author': 1, 'fields[1]': 'Title 123', 'fields[2]': 'Content ABC'} 2024-03-21 11:12:21 - DEBUG - Starting new HTTP connection (1): localhost:80 2024-03-21 11:12:21 - DEBUG - http://localhost:80 "POST /api/index.php?/cms/records/1&key=ef2f4f1687b901d3c962f074dcd4528e HTTP/1.1" 201 1109

Thanks @teraßyte. I noticed the edit aspect and had mentioned that earlier. I would think any POST to create a new record would fail in this case (which is what I'm experiencing across 3 different Pages DBs), but @Marc Stridgen wasn't able to reproduce it. @Marc Stridgen can you confirm you tested on 4.7.16?

I'll do some more testing today. FWIW, the GET to the hello endpoint works fine. I'll also get appropriate errors when the POST executes and determines something like an invalid category or author. 2024-03-21 10:21:24 - INFO - post_cms_record_url: http://localhost/api/index.php?/cms/records/1 2024-03-21 10:21:24 - INFO - post_data: {'category': 99, 'author': 1, 'fields[1]': 'Title 123', 'fields[2]': 'Content ABC'} 2024-03-21 10:21:24 - DEBUG - Starting new HTTP connection (1): localhost:80 2024-03-21 10:21:24 - DEBUG - http://localhost:80 "POST /api/index.php?/cms/records/1&key=ef2f4f1687b901d3c962f074dcd4528e HTTP/1.1" 400 72 Ran 1 test in 0.094s OK Error: 400 Response: {'errorCode': '1T306/5', 'errorMessage': 'NO_CATEGORY'} Regarding the hooks being disabled, that did not resolve the issue. 2024-03-21 10:25:57 - INFO - post_cms_record_url: http://localhost/api/index.php?/cms/records/1 2024-03-21 10:25:57 - INFO - post_data: {'category': 1, 'author': 1, 'fields[1]': 'Title 123', 'fields[2]': 'Content ABC'} 2024-03-21 10:25:57 - DEBUG - Starting new HTTP connection (1): localhost:80 Error: 500 Response: {'errorCode': 'EX1048', 'errorMessage': 'UNKNOWN_ERROR'} 2024-03-21 10:25:58 - DEBUG - http://localhost:80 "POST /api/index.php?/cms/records/1&key=ef2f4f1687b901d3c962f074dcd4528e HTTP/1.1" 500 72

FWIW... # With API Key in request params returns 500 and EX1048 response = requests.post(post_cms_record_url, data=post_data, params=request_params) # With API Key base64 encoded in headers # Error: 401 # Response: {'errorCode': '3S290/7', 'errorMessage': 'INVALID_API_KEY'} response = requests.post(post_cms_record_url, data=post_data, headers=headers) # With API Key in auth returns 500 and EX1048 response = requests.post(post_cms_record_url, data=post_data, auth=auth)

Right and I believe that's due to the first screenshot I posted where it's expecting a record_id when one doesn't exist yet since this is creating a record, not editing one. Unless that DB update is made after the record is created (but not committed yet), I don't know the sequencing or transactionalization of their DB commands for the API. Maybe it's due to the api key being a request param instead of a header, but the header approach wouldn't work for me before this current version of the software.

I dropped the data parsing for the non-200 case, here is that output: 2024-03-20 16:38:05 - INFO - post_cms_record_url: http://localhost/api/index.php?/cms/records/1 2024-03-20 16:38:05 - INFO - post_data: {'category': 1, 'author': 1, 'fields[1]': 'Title 123', 'fields[2]': 'Content ABC'} 2024-03-20 16:38:05 - DEBUG - Starting new HTTP connection (1): localhost:80 2024-03-20 16:38:05 - DEBUG - http://localhost:80 "POST /api/index.php?/cms/records/1&key=ef2f4f1687b901d3c962f074dcd4528e HTTP/1.1" 500 72 Ran 1 test in 0.179s OK Error: 500 Response: {'errorCode': 'EX1048', 'errorMessage': 'UNKNOWN_ERROR'}

It's just a python script, I put this together to post to the default Articles Pages DB and get a 500 as well. def test_api_cms_post(self): post_cms_record_url = f"{self.API_URL}{self.CMS_RECORDS_ENDPOINT}1" logging.info(f"post_cms_record_url: {post_cms_record_url}") # Request parameters with API key included in the URL request_params = { 'key': self.API_KEY } post_data = {'category': 1, 'author': 1, 'fields[1]': 'Title 123', 'fields[2]': 'Content ABC'} logging.info(f"post_data: {post_data}") # Make a POST request to the API endpoint response = requests.post(post_cms_record_url, data=post_data, params=request_params) # Check if the request was successful (status code 200) if response.status_code == 200: # Parse the JSON response data = response.json() # Process the data as needed print("Response:", data) else: # Print an error message if the request was not successful print(f"Error: {response.status_code}") Output: 2024-03-20 16:13:43 - INFO - post_cms_record_url: http://localhost/api/index.php?/cms/records/1 2024-03-20 16:13:43 - INFO - post_data: {'category': 1, 'author': 1, 'fields[1]': 'Title 123', 'fields[2]': 'Content ABC'} 2024-03-20 16:13:43 - DEBUG - Starting new HTTP connection (1): localhost:80 Error: 500 2024-03-20 16:13:43 - DEBUG - http://localhost:80 "POST /api/index.php?/cms/records/1&key=ef2f4f1687b901d3c962f074dcd4528e HTTP/1.1" 500 72 Ran 1 test in 0.140s OK

I tried another Pages DB and POST call that worked before the update and it too is getting the same error.

Was working on something new and started issuing POSTs to a Pages DB but it's erroring with a 500. System log entry below. Being this is a create of a record via a POST, I'm not sure why it is triggering an edit (requiring a record_id) which is also via a POST.

Awesome! Thanks John for the very detailed reply and providing your experiences! That's very helpful!