Api.php transport not populating array

It appears the Api.php Transport method is not properly builing the $api array.

Unfortunately I am not especially conversant in php, but I can see the post request is empty of data and after some testing I can see the $obj variable has data but the foreach loop isn’t properly building the $api array

foreach ($obj as $k => $v) {
$api = str_replace("%" . $k, $method == “get” ? urlencode($v) : $v, $api);
}

Was there a recent change to the $obj structure? Could anyone more familiar with php provide some assistance? Is the api transport method not in use, should i try using another transport? I need ideally a json object with the alert so I can integrate this with our monitoring service.

Thank you,

Hi @Steven_Pine
There is a PR coming on the API Transport, with a major rewrite. But the current code is working.
Like ‘%title’ is replaced with the title of the alert etc etc.
Could you post here a (sanitized) version of your API url ?

I am pushing POST requests to localhost, and on my listener I see no data:
‘’’
got connection from (‘127.0.0.1’, 46108)
POST / HTTP/1.1
Host: 127.0.0.1:5000
Accept: /
Content-Length: 0
Content-Type: application/x-www-form-urlencoded
‘’’

I modified the file to dump the $obj and $api vars, and the $api is empty.

perhaps the $obj is unusual? It is a wall of text with array in the middle, as well as the macro and at the bottom is the typical alert we would see if we push it to slack or another transport method.

having trouble posting the $obj as a new user, trying a screenshot of it instead.

Did you try using GET method ? You may face issue with size but at least it would help identify the issue.
As mentioned before, if you have a couple of weeks you can wait, a new API transport is on the way right now in GitHub.

No, that doesn’t help:
got connection from (‘127.0.0.1’, 35474)
GET /? HTTP/1.1
Host: 127.0.0.1:5000
Accept: /
Content-Length: 0
Content-Type: application/x-www-form-urlencoded
~~

again, the issue is the var $api is empty – I pasted a txt dump of the $obj above, is there something unusual about it? Again, other transport methods like slack work just fine, which suggests an issue with the Api.php code. If i were more familiar with php I would try to fix it myself.

Can you point me to the github api code that will be merged in the next few weeks?

Any help is much appreciated.

Code is here :

You should only apply it on a test machine for the moment as it will break any other API Transports on your system.

Thanks Pipo,

will this support sending POST requests with json data? I’ll assume with this coming so soon there will be no fix to the current Api.php?

For context, I originally wrote an integration with your api and our monitoring service, but the api doesn’t return the template alert messages, and I also need to approximate the alert details by making a second request with a timestamp ( this is where i ran into your timestamp documentation issue).

If the librenms api would provide this information I could go back to that, but instead I need to rewrite this service to receive post data. perhaps I am going about this all wrong and there is a better way to do this?

Thank you again,

Everything can be done if there is a simple fix for your issue, but we need first to identify it.

Concerning the new code, the idea is to send POST data with the “option field” sent as urlencoded data. One parameter per row. The parameters that are available are the same as the one in the templates, basically.
like this :

msg=My title is {{ $title }}
device=My device is {{ $hostname }}
user=titi
api_key=toto

And concerning your original issue, you should probably write code (or make a detailed feature request) to directly use LibreNMS api.

The reason I posted here is because the Api.php is sending an empty array, i’d like that fixed.

barring that, maybe you help help me understand the $obj and I can rewrite the api.php myself to send a json.

Otherwise I can go over my api integration code and point out areas I would like it to be different or provide better data.

  • For the LibreNMS API -> Feature Request with as many details as possible.

  • For the API Transport:

    • Current code is working OK with limitations on templating with GET requests. I did not test it in POST but I see no real reason to break so far. More testing needed.
    • New one is working well in both GET and POST.
    • If you give me your API Transport current settings (URL …), I can have a look.
    • Best would be that you test the new code, so we can validate it in your env.

Thanks Pipo. I appreciate your assistance and will get back to you.

I will look into the feature request, but for the immediate matter at hand, here is the api transport configuration:

As you can see, just sending data to localhost
I wrote a dead simple python listener:
~~

import socket
import time

s = socket.socket()
print “Socket successfully created”

port = 5000
s.bind((‘127.0.0.1’, port))
print “socket binded to %s” %(port)

s.listen(5)

print “socket is listening”

while True:
c, addr = s.accept()
print ‘got connection from’, addr

data = c.recv(4096)
print str(data)
#print data.decode()

c.send('thank you for connecting')
time.sleep(10)
print 'closing'
c.close()

Here what is reports:

got connection from (‘127.0.0.1’, 57290)
GET /? HTTP/1.1
Host: 127.0.0.1:5000
Accept: /
Content-Length: 0
Content-Type: application/x-www-form-urlencoded
~
You can see the GET /? is empty.
I rewrote the Api.php for testing, and am writing $obj and $api to a static file, i already provided a screenshot of $obj, and $api is consistently empty.
If i say write $obj[‘msg’] to a file it prints what i expect it to print.

Here an example rule:

Hopefully this is enough information to identify the issue, and to prove that the $api array is empty.

In your API URL, you don’t pass anything so the API transport does not send anything. This is expected.

Try this, in with GET method.
http://127.0.0.1:5000?title=%title

You should get the title passed as the “title” variable.

Fantastic, I am seeing data. The documentation could be significantly clearer that this information needs to be in the api method.

thanks again for your help. I will still try to make a feature request as mentioned for the api.

Sincerely,

The new PR already has more documentation :slight_smile: