New action: message

[doits]

It would be nice to have action buttons that simply send a message back when pressed, for example:

ntfy publish \
    --actions '[
        {
            "action": "message",
            "label": "Turn down",
            "message": "Yes, turn down the A/C",
            "priority": 4
        }
    ]' \
    myhome \
    "You left the house. Turn down the A/C?"

When clicked, the message Yes, turn down the A/C (key: message) is sent to the topic with priority 4 (key: priority) by the client.

This could be used by other subscribers of the topic to:

• do something (something subscribed to the topic and listening for specific messages, e.g. a server waiting for commands to do some home automation)
• as a fast response to an incoming message (e.g. if the notification is a alert multiple people receive, one person could notify the others that they will take care of it)

What do you think about the idea?

[wunter8]

You can send messages to ntfy topics using the existing HTTP action, but creating a shorthand action to do this might be nice.

ntfy publish \
    --actions '[
        {
            "action": "http",
            "label": "Turn down",
            "url": "https://ntfy.sh",
            "method": "POST",
            "body": "{
                \"topic\": \"myhome",
                \"message\": \"Yes, turn down the A/C\",
                \"priority\": 4
            }"
        }
    ]' \
    myhome \
    "You left the house. Turn down the A/C?"

(I didn't test the above command specifically, but I've done it in the past and this is the idea)

[doits]

Ah right good idea that you can simply do it like this. Couldn't test it yet, maybe you know if this works with credentials? E.g. if the topic can only be accessed/posted to with authentication, will it use the same credentials the topic is subscribed with?

[wunter8]

I'm pretty sure it won't use the same credentials the topic is subscribed with. You could test it out and see. If I'm right and it doesn't include the authentication automatically, you can just add an Authorization header into the HTTP action: https://docs.ntfy.sh/publish/#send-http-request

[doits]

you can just add an Authorization header into the HTTP action

Yeah, I thought about this, too, though this would give write access to everybody receiving the message (might be OK, depending on the scenario), BUT if the authorization header could be extracted from the message (probably not with the default ntfy client, but in theory since it is sent to the client) it could be used to write arbitrary things to the topic, even at a later time when the user is removed from that topic (unless the shared credentials are rotated ...).

So I feel this is not the best way to implement this scenario securely (in fact every scenario where a long lived, shared authorization header is sent, because it could be misused for other things or at a later time where maybe a user should not have access anymore).

I'll test a little bit and see what I can come up with for my scenario.

[wunter8]

Automatically sending a client's authentication to every HTTP action wouldn't be great either because you'd be leaking creds. But the client could probably be updated to check if the URL of the HTTP action is one that has saved credentials already, then send the HTTP request using the saved credentials. That doesn't sound too bad to me.

[wunter8]

binwiederhier is also working on revokable access tokens right now. So you could send a short lived (they can be created with an expiration date/time) access token as a header in the HTTP action instead of a specific user:pass combination

[doits]

Automatically sending a client's authentication to every HTTP action wouldn't be great either because you'd be leaking creds

Yeah, of course, it should be sent only if sending a message to the topic where on actually is subscribed to with some credentials (not in general for a REST message, that was never the idea). That would be possible with a separate action (which this issue is about in the first place).

But the client could probably be updated to check if the URL of the HTTP action is one that has saved credentials already, then send the HTTP request using the saved credentials. That doesn't sound too bad to me.

:+1: that would solve it.

binwiederhier is also working on revokable access tokens right now. So you could send a short lived (they can be created with an expiration date/time) access token as a header in the HTTP action instead of a specific user:pass combination

This would solve it, too. So let's see where this goes.