API System giving 404 errors

[mwarner]

No dice. I disabled the default Apache configuration (000-default) and even set a ServerAlias for fog.emg-usa.com (where I, as you correctly guessed, typically visit the site from) in the 001-fog configuration file.

I did try replacing the DNS name with an IP and still no luck. My IP for the main FOG server is, let’s call it, 10.1.10.254 and I tried the following endpoints:

10.1.10.254/fog/task/current
10.1.10.254/fog/api/task/current
10.1.10.254/task/current

all of which received a 404 error. Same thing with the new ServerAlias added. I made sure to restart the apache2 service after each edit to the config files.

Interestingly enough, 10.1.10.254/fog/api returns a 403 Forbidden, but after investigating the api/index.php file it doesn’t seem to shed any light into the issue (at least from what I saw).

[Tom Elliott]

@mwarner A 403 means you’re missing the FOG-API-Token.

401 (after getting fog-api-token set and sent) = you aren’t using a user token/basic auth to get information.

[mwarner]

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

[Tom Elliott]

Can you post a copy of your current /etc/apache2/sites-enabled/001-fog.conf please?

[mwarner]

@tom-elliott

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!

[Tom Elliott]

@mwarner Loose the “api” portition of the call. ALl requests are happening via /fog/<item>/<item>

/fog/api/<item> is invalid

[mwarner]

@tom-elliott it still returns a 404 without /api in the URL

[Tom Elliott]

trying to hit you on chat.

[mwarner]

@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

[Tom Elliott]

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.

[Tom Elliott]

You think it’s safe to solve this now?

[Wayne Workman]

The examples I posted do have the /fog directory included in them.

[mwarner]

@Tom-Elliott Yes it is safe to solve now, sorry for the delay. Thanks again!