API Token is missing or invalid

Hi all,

New LibreNMS installation on Ubuntu 16.04 with nginx, having followed the official documentation at http://docs.librenms.org/Installation/Installation-Ubuntu-1604-Nginx/. I am experiencing issues with Libre API access (for Oxidized integration in this case).

I’ve successfully configured and deployed several LibreNMS + Oxidized CentOS 7 (with nginx) without problem before, however on this new Ubuntu installation I am experiencing API issues when trying to test the API for Oxidized via curl.

curl -H ‘X-Auth-Token: c5b4314f1f2719f5c0f1bf4c248d7d767’
“status”: “error”,
“message”: “API Token is missing or invalid; please supply a valid token”

The token has been created in the Libre WebUI, and all appears fine with that… however, I can access no part of the API. I have tried with further tokens, however the same issue persists.

The curl API call generates the following access_log entry: - - [05/Jun/2017:14:26:52 +0100] “GET /api/v0/oxidized HTTP/1.1” 401 115 “-” “curl/7.47.0”

Output of ./validate.php below.


Component Version
LibreNMS c67424b4efc4ae2591dde349bb37b163eb6e8ba2
DB Schema 194
PHP 7.0.18-0ubuntu0.16.04.1
MySQL 10.0.29-MariaDB-0ubuntu0.16.04.1
RRDTool 1.5.5


Any thoughts/assistance would be most appreciated please :slight_smile:

What authentication method are you using?

Hi laf, MySQL auth. config.php as follows.

### Database config
$config['db_host'] = 'localhost';
$config['db_port'] = '3306';
$config['db_user'] = 'librenms';
$config['db_pass'] = 'REMOVED';
$config['db_name'] = 'librenms';
$config['db_socket'] = '';
$config['db']['extension'] = "mysqli";// mysql or mysqli

// This is the user LibreNMS will run as
//Please ensure this user is created and has the correct permissions to your install
$config['user'] = 'librenms';

### Memcached config - We use this to store realtime usage
$config['memcached']['enable']  = FALSE;
$config['memcached']['host']    = "localhost";
$config['memcached']['port']    = 11211;

### Locations - it is recommended to keep the default
$config['install_dir']  = "/opt/librenms";

### This should *only* be set if you want to *force* a particular hostname/port
### It will prevent the web interface being usable form any other hostname
#$config['base_url']        = "REMOVED";

### Enable this to use rrdcached. Be sure rrd_dir is within the rrdcached dir
### and that your web server has permission to talk to rrdcached.
#$config['rrdcached']    = "unix:/var/run/rrdcached.sock";

### Default community
$config['snmp']['community'] = array("REMOVED");

### Authentication Model
$config['auth_mechanism'] = "mysql"; # default, other options: ldap, http-auth
#$config['http_auth_guest'] = "guest"; # remember to configure this user if you use http-auth

### List of RFC1918 networks to allow scanning-based discovery
#$config['nets'][] = "";
#$config['nets'][] = "";
#$config['nets'][] = "";

# Uncomment the next line to disable daily updates
#$config['update'] = 0;

# Enable billing module
$config['enable_billing'] = 1;
$config['billing_data_purge'] = 36;

Look in mysql, SELECT * from api_tokens;

Get the user_id and do SELECT * from users where user_id=X; - Replace X with the user_id from above. Do you get your user info back?

Hi laf,

Yes that query returns the correct associated username.

Wonder if it’s an nginx thing and it’s stripping the header out.

Before if (!empty($username)) { in html/includes/api_functions.inc.php add this:


Re-run the api call and see what’s output.

OK this is what I get back now:

[email protected]:~$ curl -H ‘X-Auth-Token: c5b4314f1f2719f5c0f1bf4c248d7d767’
c5b4314f1f2[email protected]bo-qtp-nms1:~$

My understanding is that should have echo’d back the actual libre username associated with the token? If that’s the case, it didn’t echo it back correctly (but instead appears to have echo’d back the token hash twice)??

The token twice is correct but yes, missing the username is an issue.

Above the code you changed, you will see $username = twice. Above each one put (but change FIRST to SECOND for the second one):


Ok and here’s the new output:


Run this in mysql SELECTAT.user_idFROMapi_tokensAS AT WHEREAT.token_hash= 'c5b4314f1f2719f5c0f1bf4c248d7d767';

I realise you’ve probably added more tokens but this last one is different from your original

That’s still the same token hash as the original one I posted? Or am I missing something? I have added (and subsequently deleted) several others for testing, however I’ve been sticking to this original one (c5b4314f1f2719f5c0f1bf4c248d7d767) for all tests.

MariaDB [librenms]> SELECT AT.user_id FROM api_tokens AS AT WHERE AT.token_hash= ‘c5b4314f1f2719f5c0f1bf4c248d7d767’;
Empty set (0.00 sec)

Ok upon closer examination I see that the token you just asked me to test has an additional ‘7’ character appended to it compared to my original token.

Token you asked me to test:

MariaDB [librenms]> SELECT AT.user_id FROM api_tokens AS AT WHERE AT.token_hash= ‘c5b4314f1f2719f5c0f1bf4c248d7d767’;
Empty set (0.00 sec)

Correct and configured token:

MariaDB [librenms]> SELECT AT.user_id FROM api_tokens AS AT WHERE AT.token_hash= ‘c5b4314f1f2719f5c0f1bf4c248d7d76’;
| user_id |
| 1 |
1 row in set (0.00 sec)

I think the penny just dropped about how stupid I have been… I have no idea how that additional character sneaked into all of my testing!

Curl output now…

[user_id] => 1
[username] => REMOVEDHERE
[password] => REMOVEDHERE
[realname] =>
[email] => REMOVEDHERE
[descr] =>
[level] => 10
[can_modify_passwd] => 1
[created_at] => 1970-01-02 00:00:01
[updated_at] => 2017-06-05 12:40:11
[remember_token] =>

I’ll thank you extensively, get my coat, and remove the code modifications :slight_smile: