starred/ntfy

Fork 0

mirror of https://github.com/binwiederhier/ntfy.git synced 2026-05-09 08:26:00 +02:00

[GH-ISSUE #550] New action: message #416

New issue

Open

opened 2026-05-07 00:23:57 +02:00 by BreizhHardware · 7 comments

BreizhHardware commented

2026-05-07 00:23:57 +02:00

Owner

Originally created by @doits on GitHub (Dec 17, 2022).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/550

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?

Originally created by @doits on GitHub (Dec 17, 2022). Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/550 It would be nice to have action buttons that simply send a message back when pressed, for example: ```bash 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?

BreizhHardware added the

android-app

enhancement

labels

2026-05-07 00:23:57 +02:00

BreizhHardware commented

2026-05-07 00:23:57 +02:00

Author

Owner

@wunter8 commented on GitHub (Jan 17, 2023):

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)

@wunter8 commented on GitHub (Jan 17, 2023): 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)

BreizhHardware commented

2026-05-07 00:23:58 +02:00

Author

Owner

@doits commented on GitHub (Jan 29, 2023):

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?

@doits commented on GitHub (Jan 29, 2023): 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?

BreizhHardware commented

2026-05-07 00:23:58 +02:00

Author

Owner

@wunter8 commented on GitHub (Jan 29, 2023):

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

@wunter8 commented on GitHub (Jan 29, 2023): 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

BreizhHardware commented

2026-05-07 00:23:58 +02:00

Author

Owner

@doits commented on GitHub (Jan 29, 2023):

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.

@doits commented on GitHub (Jan 29, 2023): > 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.

BreizhHardware commented

2026-05-07 00:23:58 +02:00

Author

Owner

@wunter8 commented on GitHub (Jan 29, 2023):

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 commented on GitHub (Jan 29, 2023): 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.

BreizhHardware commented

2026-05-07 00:23:58 +02:00

Author

Owner

@wunter8 commented on GitHub (Jan 29, 2023):

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

@wunter8 commented on GitHub (Jan 29, 2023): 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

BreizhHardware commented

2026-05-07 00:23:58 +02:00

Author

Owner

@doits commented on GitHub (Jan 29, 2023):

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.

👍 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.

@doits commented on GitHub (Jan 29, 2023): > 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.