API System giving 404 errors
-
@Tom-Elliott Right, but if I attach a proper endpoint (say /api/task/current) I get a 404. As far as I’m aware, /api by itself is useless and that seems to be the only endpoint sending a meaningful response (one that isn’t “not found”).
-
Can you post a copy of your current /etc/apache2/sites-enabled/001-fog.conf please?
-
NameVirtualHost *:80 <VirtualHost *:80> KeepAlive Off ServerName 10.1.10.254 ServerAlias fog.emg-usa.com DocumentRoot /var/www/ <Directory /var/www/fog/> DirectoryIndex index.php index.html index.htm </Directory> RewriteEngine On RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-d # RewriteRule ^\/(.*)$ /fog/api/index.php [QSA,L] </VirtualHost>
Just realized that I tried to comment out the RewriteRule in an attempt to get it working earlier. I just uncommented it and it works fine. So it definitely was the missing ServerAlias that was causing the issue.
fog.emg-usa.com/fog/api/task/current
and
10.1.10.254/fog/api/task/current
are both returning 403 errors now. I’ll add an API key in a moment to see if we can get some actual data back along with a 200 code!
-
@mwarner Loose the “api” portition of the call. ALl requests are happening via /fog/<item>/<item>
/fog/api/<item> is invalid
-
@tom-elliott it still returns a 404 without /api in the URL
-
trying to hit you on chat.
-
@Tom-Elliott I take that back, it returns a 403 in the browser but when I use CURL it returns 0 bytes of data unless I use /api in the URL
-
Remoted with @mwarner and we were able to fix the problem.
They were accessing the api using :<url>/task/current when it should’ve been :<url>/fog/task/current.
The confusion came because they weren’t expecting to need the /fog portion as they allow the :<url> to go directly to the fog gui.
-
You think it’s safe to solve this now?
-
The examples I posted do have the /fog directory included in them.
-
@Tom-Elliott Yes it is safe to solve now, sorry for the delay. Thanks again!