Hello,

I am running IC 4.7.20, running PHP 8.1.31 on an Apache web host. I've uploaded the .htaccess file to the recommended folder and and renamed the file. I have confirmed the file is indeed there, however, I keep getting presented this same message.

 

API

In order to use the REST API:

1. Download this file.

2. Upload it to the /api folder in your site's directory (/var/www/vhosts/test.mydomain.com/api).

3. Rename it to '.htaccess' (with no file name).

You would need to check with your hosting provider to see if your server has enabled the items in the .htaccess and it is indeed working.

 

You would need to check with your hosting provider to see if your server has enabled the items in the .htaccess and it is indeed working.

The mod_setenvif module is indeed enabled on the Apache server, loaded, and is working. However, the API check script in the Admin Panel is not recognizing it for some reason.

Is this something new? The API check script. Because it works fine on my existing server, however, the new server that I'm testing is not accepting the fact that the mod_setenvif module is loaded and working.

Edited February 22Feb 22 by NAWAC

It would be mod rewrite you would be checking.

 

It would be mod rewrite you would be checking.

I've checked just about everything, including mod_rewrite, which is also working on my server. I've spent probably 20 plus hours trying to debug to get the Admin Panel to clear this message, however, everything on my server is working. Apache is working, .htaccess is working, mod_setenvif and mod_rewrite are all working, including my own PHP test script with all them working together. The problem seems to be an internal Admin Panel problem getting past this screen.

In my test script I used both mod_setenvif and mod_rewrite in the /api/ directory, same as your .htaccess file is using, and my test file works with the mod_setenvif and the mod_rewrite, so Apache is configured properly and so is PHP. The problem appears to be with the API section of the Admin Panel. The Admin Panel will not let me into the API section. It gives the same old message below. I've used the API system in times past extensively and I am still using it. However, on this new server hardware that I'm testing to be compatible with the upcoming Version 5, I cannot access the API tools in the Admin Panel. I'm running v4.7.20 on both the Live site and the Test site. I guess I don't know where this .htaccess file thingy came from, because it's not required now on my live site, but on the test site it is required, even though they are v4.7.20.

Edited February 24Feb 24 by NAWAC

Are you using CloudFlare or another WAF product which may be blocking the request? I've seen this before when other sites are using CloudFlare, it is accidentally blocking their own server so the test request fails and it thinks the .htaccess isn't there.

I'm not using CloudFlare and the Web Application Firewall (ModSecurity) is turned OFF in Plesk.

Edited February 24Feb 24 by NAWAC

We would need to look further into this for you, however the access details on file appear to be incorrect or missing. Could you please update these details by visiting your client area, selecting the relevant purchase, then clicking "Review/Update Access Information" under the "Stored Access Information" section. 

We look forward to further assisting you. 

It's worth noting, that I am getting a 404 Not Found error when going to {your-base-url}/api/core/hello/ so it looks like URL rewrites are not working on your server. Additionally, it does not look like you have rewrites enabled for the main community portion either. You will want to test this with your hosting provider to ensure that rewrites are working appropriately.

 

It's worth noting, that I am getting a 404 Not Found error when going to {your-base-url}/api/core/hello/ so it looks like URL rewrites are not working on your server. Additionally, it does not look like you have rewrites enabled for the main community portion either. You will want to test this with your hosting provider to ensure that rewrites are working appropriately.

You're talking about my test site, correct?

When I type in {my-base-url}/api/core/hello/ I get the following results:

{
    "errorCode": "3S290\/7",
    "errorMessage": "INVALID_API_KEY"
}

Is that what it's supposed to say? What is supposed to happen? Is it supposed to redirect somewhere, and if so, where? Then I can test it.

Edited February 24Feb 24 by NAWAC

That's the correct response when it's trying to test if the .htaccess is present.

Here's my test to prove mod_setenvif and mod_rewrite is indeed working inside the /api/ directory, as you require.

The file contents of your .htaccess file is the following:

<IfModule mod_setenvif.c>
	SetEnvIf Authorization .+ HTTP_AUTHORIZATION=$0
</IfModule>
<IfModule mod_rewrite.c>
	Options -MultiViews
	RewriteEngine On
	RewriteBase /api/	
	RewriteCond %{REQUEST_FILENAME} !-f
	RewriteCond %{REQUEST_FILENAME} !-d
	RewriteRule .* index.php [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]
</IfModule>

I decided to perform a test to see if mod_setenvif and mod_rewrite are working as expected. So, in lieu of your .htaccess file, I created my own .htaccess file in the /api directory with the following contents:

<IfModule mod_setenvif.c>
	SetEnvIf Request_URI "^.*test.*$" TEST_MOD_SETENVIF=99
</IfModule>
<IfModule mod_rewrite.c>	
	RewriteEngine On
	RewriteBase /api/	
	RewriteRule test.html test_api.php
</IfModule>

I then created a test_api.php file inside the /api/ directory. The test_api.php file contains the following code:

if (getenv('TEST_MOD_SETENVIF')) {
	echo "mod_setenvif is loaded! TEST_MOD_SETENVIF=".getenv('TEST_MOD_SETENVIF')."<br>";
} else {
	echo "mod_setenvif is NOT loaded.<br>";
}

I then try to access the following URL on my test site: {my-test-site-domain}/api/test.html

Note, the file /api/test.html does not physically exist on the server, this is to verify and prove that mod_rewrite is indeed working. If mod_rewrite is working, it will rewrite to test_api.php instead of trying to use test.html which does not even exist.

The results gave the following echoed to the browser when accessing {my-test-site-domain}/api/test.html,:

mod_setenvif is loaded! TEST_MOD_SETENVIF=99

What does this prove? That Apache is working, .htaccess is working, mod_setenvif and also mod_rewrite are all working inside the /api directory, as required by your api system. The only conclusion that I can come up with is that your supplied .htaccess file in conjunction with your requirements for the API check inside the Admin Panel is not working as intended.

 

You're talking about my test site, correct?

No. Your test site is behind a .htaccess/.htpasswd which would prevent the system from access the API so that would be expected.

 

No. Your test site is behind a .htaccess/.htpasswd which would prevent the system from access the API so that would be expected

Well, this is frustrating, to say the least. As I stated previously,

 

...it works fine on my existing server, however, the new server that I'm testing is not accepting the fact that the mod_setenvif module is loaded and working.

I spent many, MANY hours debugging something that wasn't necessary. I temporarily took out the basic auth/password protection on my test server and the API worked as expected.

How can I test the API on a TEST SERVER if the system will not allow it because of the basic auth/password required on test sites?

 

Well, this is frustrating, to say the least. As I stated previously,

I spent many, MANY hours debugging something that wasn't necessary. I temporarily took out the basic auth/password protection on my test server and the API worked as expected.

I apologize that you're frustrated and this was not clear to us that you were using a Test URL. That line means different things to different people and we got there in the process. In the future, you can explicitly state you're on your Test URL, test Invision Community installation, or test license key to ensure we are on the same page.

Test URLs also are outside our scope of support so inherently, we would not gravitate towards that naturally in our own investigations.