Issue when enabling Zapier

[Thomas Hop]

 

Hello,

We have been trying to enable “Zapier” in integrations, however we get an error code (see image1).

We tried the suggested solution (image2), however we can’t get it to work. Is there maybe something we can do to fix this?

Thanks in advance!

[Sonya*]

1 hour ago, Thomas Hop said:

Is there maybe something we can do to fix this?

Currently, your entire subdomain is protected by login/password. The API can only reach URLs that are public.

[Marc Stridgen]

[Daniel F]

For your API testing you could also just "whitelist" specific files/directories, in this case the api/ directory, so that everything except the api directory requires a htaccess password.

 

[Thomas Hop]

Thank you for the replies, however this is not the issue (forget to mention), because I have tried a few things like disabling the .htpasswd authentication temporarily, also we tried (are trying) to do this on our production environment, which doesn’t require .htpasswd verification and this also doesn't work/gives the same message. 

[Daniel F]

What happens when you call the HELLO endpoint with the key attached to the URL directly in your browser? Do you see any error? ( yourURL/api/index.php?/core/hello&key=abcdefg.. )

 

[Thomas Hop]

@Daniel F

Thank you for the help, however i can’t test this, as i don’t have an API key and when i try to make one on the using the AdminCP: (see image) 

I get the same error as before when enabling Zapier, I have access to the DB and see that the “core_api_keys” table is empty, if possible I could just add one here manually? (No idea what values need to be inserted however)

Else when when accessing the URL manually (without correct API key) I am getting the notification:  

{

    "errorCode": "3S290\/7",

    "errorMessage": "INVALID_API_KEY"

}

 

[Marc Stridgen]

Do you have rewriting switched on within your site?

[Thomas Hop]

Yes we have, there is also a notification there: (see image), also can’t get this error to go away, tried using the .htaccess that is provided, but to no avail.  

[Jim M]

2 minutes ago, Thomas Hop said:

Yes we have, there is also a notification there: (see image), also can’t get this error to go away, tried using the .htaccess that is provided, but to no avail.  

This would be why it is not working. Are you using a firewall which may be blocking access or changing the response? If the system receives a response it is not expecting then it will generate all these errors which you are experiencing here. I would suggest temporarily adding a whitelist for your server to get by any firewalls and removing any .htaccess items except for our own.

[Thomas Hop]

Hello,

I had contact with the hosting provider, this however did not resolve much, he needed specifics about the request that is being made (port etc). I must admit I am a bit of a fish out of water, so I couldn't narrow it down further what information he needs.

Is there any technical documentation of how this works? Or can you tell me what URL's / Ports need to be opened on the server?

Hopefully, you can help me with this.

Thanks. 

[Marc Stridgen]

These are things that would be accessed on general web ports (80 and 443 for example), so it's very very unlikely to be that I would think. 

 

[Thomas Hop]

Thanks for the informatie, however is there maybe something we can use to test? Something like mentioned before: “( yourURL/api/index.php?/core/hello&key=abcdefg.. )” however something that doesn’t require an API key (because I can’t make one).

[Marc Stridgen]

You would go to that page in the ACP as that is indeed testing

[Sonya*]

On 3/11/2024 at 5:25 PM, Thomas Hop said:

Yes we have, there is also a notification there: (see image), also can’t get this error to go away, tried using the .htaccess that is provided, but to no avail.  

I had this error on ngnix server, that does not support .htaccess. Enabling proxy mode has helped to resolve.

Another time the error has been shown while elastic search was misconfigured. Once I disabled elastic, the error was gone.

[Clover13]

@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.  

[Clover13]

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.

[Marc Stridgen]

Check you havent got anything else rewriting below that level which is not IPS related that may be interfering with it on those 2 sites.

[Clover13]

8 hours ago, Marc Stridgen said:

Check you havent got anything else rewriting below that level which is not IPS related that may be interfering with it on those 2 sites.

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.  

[Nathan Explosion]

25 minutes ago, Clover13 said:

...prompting me to install the htaccess file in the api directory (which I did)...

Just because you didn't specifically menion it - after putting the file in the /api folder, did you rename it so that it comes into effect?

The file downloaded is called htaccess, so did you rename it to .htaccess when you put it in the /api folder?

[Clover13]

6 minutes ago, Nathan Explosion said:

Just because you didn't specifically menion it - after putting the file in the /api folder, did you rename it so that it comes into effect?

The file downloaded is called htaccess, so did you rename it to .htaccess when you put it in the /api folder?

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.

[Marc Stridgen]

1 hour ago, Clover13 said:

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 code for each is exactly the same, so really it could only be hosting level I would think

[Clover13]

3 hours ago, Marc Stridgen said:

The code for each is exactly the same, so really it could only be hosting level I would think

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?

[Jim M]

50 minutes ago, Clover13 said:

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.

 

You would want to ensure your configuration for all sites are the same. Just because they are all on the same server, does not mean they are configured the same. Maybe there's a php.ini or .htaccess causing something screwy to happen or the opposite, the php.ini or .htaccess is required to undo something in the core configuration. Your host would need to assist you with this if you are unsure how to check these.

[Clover13]

17 hours ago, Jim M said:

You would want to ensure your configuration for all sites are the same. Just because they are all on the same server, does not mean they are configured the same. Maybe there's a php.ini or .htaccess causing something screwy to happen or the opposite, the php.ini or .htaccess is required to undo something in the core configuration. Your host would need to assist you with this if you are unsure how to check these.

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?