As an Admin currently dealing with a Kentix Siren, I would really enjoy for the HTTP Action options to be as comprehensive as they are on the RestCustomV2 Sensor. I have to give a bearer Token for authentication in this case.

Thanks a lot! :)

Customer's use case:

I have devices that are only occasionally online (laptops, dual-band Wi-Fi devices with different IPs for 2.4 or 5 GHz) and all sort of other devices that are usually offline, but for which I want to collect data automatically when they come on-line.

I have a "Script v2" sensor running regularly a Python script that fetches the list of paused devices, pings each one to see if it is online, and sends an HTTP API request to resume each device that responds to ping. This takes care of the "device reappearing" part. The required HTTP API credentials are passed securely through the %scriptplaceholder1 method provided by PRTG.

The flip side of the operation is to pause the device when it goes offline. Of course, ping is the Master sensor for the device, but unfortunately, it stays in alarm (or acknowledged alarm if so configured). When my system is running "nominal", I only want "Up" and "Paused" devices, not a ton of acknowledged "normal" alarms in which it becomes impossible to distinguish the "normal" ones that can be ignored from the ones that need to be worked on.

The quick fix is to simply create a Notification Template "Pause device" that will send a Pause HTTP API request to a sensor's parent device and add this to the Ping sensor of devices that are not expected to be online according to a regular schedule.

The issue, however, is that there is no way to securely pass the required API credentials in a Notification Template. The "Execute HTTP Action" does not support the secure placeholders. When I requested support from Paessler, the agent’s solution was to use the “Execute Program” section of the Notification Template, defining the API credentials in the OS environment itself. To me, the suggestion of putting the API token in clear text in a script file, or as a parameter visible on the command line, negates all the good security work implemented in PRTG.

PRTG goes to great lengths to protect API tokens:
• It is shown only once when creating
• It cannot be seen again when put in credentials placeholders
• Script v2 passes the credentials through a pipe, to avoid them being able to be seen on the command line.

If the Notification Template’s Execute HTTP Action section could accept secure placeholder and use them internally when generating the HTTP request, which seems simple enough at first glance, then this would preserve the credential’s security and restrict it’s use to within PRTG for this use case.