Allow a list of whitelisted HTTP status codes for the Ping Services module

Description

The issue

Currently, the Ping Services module seems to only report something as online if it receives a success status code of some sort, but there might be use-cases where non-success status codes can still indicate a service as online.

For example, I use Podgrab, and when authentication is enabled uses the browser’s Basic Authentication. This means that when the page loads it instantly returns a 401 if you’re not already logged in, which the Docker container isn’t, since I use the Docker internal bridge network as the service URL. It would still be nice to show it as online though in this case, because it is still reachable.

I think there are probably other use-cases that I can’t think of off the top of my head, but I’m sure other people would like to whitelist status codes.

Possible solutions

For the actual request mentioned in the title, it would be nice if we could input a list of allowed status codes per service if the ping module is enabled that would still return as online if it received them.

Alternatively, an option could be an integration with something like Uptime Kuma (if it supports it, I haven’t looked into it much yet) and somehow infer which service is which in UK or manually assign them, since it has the feature I want, but it would be nice to also see it on the Homarr dashboard instead of a having to open a different service.

Alternatively, an option could be to allow the user to pass on Basic Authentication information with a username and password input for the ping service (however that will only specifically target basic authentication, and not cases where other status codes are technically valid for their use-case).

Priority

Low (Nice-to-have)

Please tick the boxes

• You’ve read the docs
• You’ve checked for duplicate issues

[LarveyOfficial]

As someone who’s experiencing the same issue, please consider adding 301 (Moved Permanently) and maybe even 302 (Found / Moved Temporarily) to the whitelist too. Jackett, for example, responds with a 301 redirect to /UI/Dashboard when trying to access /.

EDIT: @Chifilly I’ve never seen 403 be used except when something really is forbidden, or in case of configuration errors (for example when directory listing is disabled). I think a(n unexpected) 403 more often than not signals a configuration error, but correct me if I’m wrong or if you’ve seen it being used in other ways.

This is the exact reason I think #228 is a good idea. It allows you to select which ones you want to be considered online. Because some people might want maybe 403, or 301, or any other code to be considered as “Online” on some services but not others.

[ajnart]

This has been implemeted with https://github.com/ajnart/homarr/pull/229 in 0.7.1