search

leiweibau / Pi.Alert

Scan the devices connected to your WIFI / LAN and alert you the connection of unknown devices. It also warns if a "always connected" device disconnects. In addition, it is possible to check web services for availability. For this purpose HTTP status codes and the response time of the service are evaluated.
https://leiweibau.net
GNU General Public License v3.0
342 stars 25 forks source link

Issue with gethomepage/homepage widget #225

Closed Aerodin closed 6 months ago

Aerodin commented 6 months ago

Hello,

I have the Homapage app to list all self hosted services in my network. I'm currently trying to get the API portion to work.

Here is the original issue I opened with Homepage in case I was doing something wrong but wanted to mention it here too: https://github.com/gethomepage/homepage/discussions/2568

Per this page it works perfectly: https://gethomepage.dev/latest/widgets/services/pialert/

Once it was up and running I then enabled login password and changed the password. I noted the API key from the config file and tried adding it in via API key when I saw that Homepage no longer could pull PiAlert details. I'm assuming the API key would need to be utilized to make the right calls but even with this setup it wasn't working. Any advice?

leiweibau commented 6 months ago

If I have read the code of "homepage" correctly, then this widget was primarily written for the original Pi.Alert.

It does not access the API, but accesses the device list directly. 

const widget = {
  api: "{url}/php/server/devices.php?action=getDevicesTotals",
  proxyHandler: genericProxyHandler,

This works until the password protection is active. The API works without the password, but when using the API, a json is returned. So if you want to use the widget, you cannot activate the password protection. If you want to use the API, the code of the widget would have to be adapted.

Aerodin commented 6 months ago

Yeah I've been trying different things to get it working - I wasn't sure if I was doing something wrong or if the API doesn't support this yet. Just trying to get the no-password display I had earlier before turning on password protection. Since I saw it has an API key that's why I started trying to pass the key: value to it to pull data.

leiweibau commented 6 months ago

Just trying to get the no-password display I had earlier before

I mistakenly asked you to add "/api/" to the URL. So you would have to remove that again. The ApiKey could also lead to an error.

I would like to go back to the different data that is provided here:

This widget queries the data from the backend directly. The backend outputs the data in this:

[56,26,6,0,0,4]

My Forkes also outputs this data via the backend without a password. However, since a password makes little sense if the backend itself does not require one, it refuses to output the data if password protection is activated. The API, on the other hand, outputs the data with the API key as follows:

{
"Scanning":"On",
"Last_Scan":"11:35:00",
"All_Devices":60,
"Offline_Devices":30,
"Online_Devices":26,
"Archived_Devices":4,
"New_Devices":0,
"All_Devices_ICMP":4,
"Offline_Devices_ICMP":3,
"Online_Devices_ICMP":1,
"All_Services":5
}

The API always works the same, whether with or without a password. I hope I have been able to shed some light on the subject.

Aerodin commented 6 months ago

Ah that helped some. Since you mentioned password I will try login/password combo with key in case the api also expects a password?

It's possible the Homepage app is still to handle password but not API? I was not sure hence the original issue raised on Homepage since I could be doing it wrong as well.

Aerodin commented 6 months ago

Ok so I'm going to start copying the API Error messages I'm getting along with the code for the Homepage used to get those error messages. I originally tried without /pialert/ but then it cannot retrieve HTTP error message comes up. With /pialert/ it says invalid data. As it in gets HTML instead of data. Removing the key attribute gets the same error as well if password protection is still on. Is a password supposed to be supplied here as well? The actual password or the password hash from the config file?

Homepage YAML:

Update 1 Will pass this along to Homepage issue page since it appears to be a widget issue.

leiweibau commented 6 months ago

My Forkes also outputs this data via the backend without a password.

Unfortunately, I have to correct this statement. Sorry for that.

In the browser, if you have already called up the pialert page, it works, but if you try a query via the command line, it does not work. The reason for this is probably that if password protection is deactivated, a session is still created, but without a password. Only this session makes it possible to "talk" to the backend. This session is apparently not created via the command line, or is not used for a second call. At this point, I have to say that there is no way around the API. Even if I offer the data "correctly" (old format) via the API, "homepage" must also use the API.

A quick fix would be to remove the password protection in the backend. But then I could leave it completely, because then it would also be possible to edit the database directly in the backend.

leiweibau commented 6 months ago

This Widget is build for the docker version of Pi.Alert

https://github.com/gethomepage/homepage/blob/main/docs/widgets/services/pialert.md

Please follow the link in the readme to the correct fork.

iraklis10 commented 6 months ago 
- Pi.Alert:
        href: http://192.168.1.XXX/pialert/
        icon: pi-alert
        description: Check Network Devices
        widget:
            type: pialert
            url: http://192.168.1.XXX/pialert

actually works with this fork too. No need for API or setting a password.

leiweibau commented 6 months ago

thank you for the feedback

Aerodin commented 6 months ago

Yeah I noted that it works without a password but with a password it won't work. For security monitoring on a network I would rather someone, should they get onto the network, not be able to tamper with the logs which makes sense from a security perspective.