Repository navigation
Allow bots to update their own messages #236
Closed
ronaldlokers
started this conversation in
Ideas
Replies: 1 comment 3 replies
|
We should expose update and destroy actions for bot messages and, as you said, keep relying on Do you want to create a PR for this? |
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
I'm using Campfire bots to post alerts from Prometheus Alertmanager into a room. Each alert fires and later resolves, and right now that's two messages — so the room becomes an append-only stream where you have to read backwards to work out what's still broken.
What I'd like is for the bot to update the message it already posted: "🚨 High memory on node-3" becomes "✅ Resolved: high memory on node-3", in place. The room then reads as current state rather than a log. The same pattern would suit anything with a lifecycle — deploys, backups, long-running jobs.
As far as I can tell the authorization model already allows this. In
app/models/user/role.rb:A bot is
record.creatorfor its own messages, soensure_can_administerinMessagesController#updatewould already pass. The only things in the way are thatconfig/routes.rbexposes justpost ":bot_key/messages", andMessages::ByBotsControllerhasallow_bot_access only: :create. CSRF is already exempt for bot-key auth.So the change looks small: a
patchroute under the:bot_keyscope, wideningallow_bot_access, and returninghead :okrather than the Turbo redirect thatMessagesController#updatedoes.The obvious objection is security, and I'd rather raise it than have it raised: a bot key is a token in a URL, scoped to a room. Today a leaked key can only add noise; with this it could rewrite history. A few ways that could be narrowed:
updateonly, nodestroy— editing is recoverable in a way deletion isn't.can_administer?, so a bot can only touch messages it created — a leaked key still can't alter anyone else's messages.All reactions