Nagios REST API throws HTP 200 with invalid api key

[WillemDH]

Hello,

We have an Ansible playbook using he Nagios REST API and noticed that even when the API key is invalid, Nagios still gives a 200 (ok). This is not really what we were expecting. Instead a 401 or 403 should be returned?

Code: Select all

{
    "content_length": "28",
    "cookies": {},
    "connection": "close",
    "x_powered_by": "PHP/7.2.25",
    "elapsed": 0,
    "invocation": {
        "module_args": {
            "directory_mode": null,
            "force": false,
            "remote_src": null,
            "status_code": [
                "200"
            ],
            "body_format": "raw",
            "owner": null,
            "follow": false,
            "client_key": null,
            "group": null,
            "use_proxy": true,
            "unix_socket": null,
            "unsafe_writes": null,
            "serole": null,
            "content": null,
            "setype": null,
            "follow_redirects": "safe",
            "return_content": true,
            "method": "POST",
            "body": "host_name=srvcentos8ks&service_description=SVC_Automatic&use=dig_srv_lin_svc_automatic_prio2&check_period=xi_timeperiod_24x7&contacts=%2Bnagiosadmin&contact_groups=%2Bcg_dummy&notification_period=xi_timeperiod_24x7&force=1",
            "url_username": null,
            "url_password": null,
            "dest": null,
            "selevel": null,
            "force_basic_auth": false,
            "removes": null,
            "http_agent": "ansible-httpget",
            "regexp": null,
            "src": null,
            "url": "https://nagios/nagiosxi/api/v1/config/service?apikey=",
            "backup": null,
            "seuser": null,
            "client_cert": null,
            "creates": null,
            "headers": {},
            "delimiter": null,
            "mode": null,
            "timeout": 120,
            "attributes": null,
            "validate_certs": true
        }
    },
    "content_type": "application/json",
    "date": "Fri, 17 Jan 2020 16:17:13 GMT",
    "_ansible_no_log": false,
    "access_control_allow_methods": "*",
    "url": "https://nagios/nagiosxi/api/v1/config/service?apikey=",
    "changed": false,
    "json": {
        "error": "Invalid API Key"
    },
    "server": "Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/7.2.25",
    "content": "{\"error\":\"Invalid API Key\"}\n",
    "access_control_allow_orgin": "*",
    "status": 200,
    "msg": "OK (28 bytes)",
    "redirected": false,
    "cookies_string": ""
}

Grtz

[mbellerue]

It returns an error in JSON format. I'm not sure I would expect it to return an HTTP status of 401 or 403, as you are successfully interacting with the API. But NGL, I haven't worked with many APIs, and hadn't thought to dig into the status codes of working or non-working commands, so I may very well be wrong here. Do you work with other APIs that work in the manner you're expecting?

[mcapra]

Most of the big public cloud providers are returning 4xx for failed authentications or insufficient permissions:
https://developer.amazon.com/docs/amazo ... codes.html
https://docs.microsoft.com/en-us/rest/a ... rror-codes
https://cloud.google.com/storage/docs/j ... atus-codes
https://www.alibabacloud.com/help/doc-detail/25491.htm

Not that "what everyone else is doing" is necessarily correct here

[mbellerue]

Oh dang, I can hear my mom now. "If all your friends implemented HTTP status codes in their REST APIs..."

Okay, I put this in as a feature request. Keep in mind that feature requests are developed at the discretion of the development team.

[WillemDH]

A rest api call with a invalid key should really throw a 403. API logs are analyzed generally based on http status codes..
Thanks for making the feature request, you can close this ticket.

[scottwilkerson]

A rest api call with a invalid key should really throw a 403. API logs are analyzed generally based on http status codes..
Thanks for making the feature request, you can close this ticket.

This has already been requested and will be changed in 5.7.0 when released.

Locking thread