Receivers can be set in the webhook request's to override the default config from the environment

[alexanderadam]

This is actually just moved from #6 (because it's not really related to Slack anyway):

You wrote:

Yes, currently this is the only way the receivers are specified. But one of the changes i want to implement (i wanted to spend some time with it tomorrow actually) is, that the receivers can be set in the webhook request's to override the default config from the environment. Since we can't specify the URL/paramters for the slack integration freely (as far as i understood it correctly, i haven't checked the documentaion yet) this won't be possible in the same way as for Grafana/Prometheus...

I thought about this as well and my initial thought was that someone could just spin a second container with other credentials.

But you are absolutely right that it would be much nicer to have just one instance that listens with different configurations.
Not only for Slack but also for Prometheus and Grafana. Because if the container is exposed outside and an attacker knows that such service is running, he could easily flood your MUC with requests. So it would make sense to add a long non guessable path to the URL anyway.

So to have an example how Slack webhook urls look like:

You can't easily guess those and therefore not easily spam your channels.

Maybe the easiest thing would be to persist the hook-configuration (the auth stuff could still be set via environment variable) in some kind of config file. For example:

webhooks:
- type: prometheus
  - channel: 'prometheus-chat@example.org'
  - url: '/foo/bar/baz/6486'
- type: grafana
  - channel: 'grafana@example.org'
  - url: '/eene/meene/mu'

But it should be mentioned that it is recommended to use a random part in the URL (i.e. by calling openssl rand -hex 23).

[tmsmr]

With https://github.com/tmsmr/xmpp-webhook/tree/overwrite_recipients we are able to pass the recipients (URL-encoded) on request-basis. E.g:

curl -X POST -d @dev/alertmanager-example.json "localhost:4321/alertmanager?recipients=recipient-b%40localhost%2Crecipient-c%40localhost"

What do you think?

[alexanderadam]

But aren't the recipients pretty much guessable? 🤔

[tmsmr]

Is this really a problem? Even with the default recipients from the ENV anyone would be able to spam / DoS them with the endpoints exposed (public, without authentication). The endpoints should be protected in any case (either network-wise or with a proxy that implements basic auth). I think i should mention that in the README with a configuration example...

[tmsmr]

@alexanderadam Any thoughts on this?

[alexanderadam]

So you mean, instead of using an unguessable URL, simpy document that it's not intended to use it with publicly available URLs?

Sure, thing. 👍
Maybe you could even direct people to a possible external solution. Something like:

xmpp-webhook is not a replacement for publicly exposed webhooks. If you need this, you should rather use a solution like Prosody with mod_slack_webhooks and simply configure an unguessable incoming_webhook_path.

[tmsmr]

I think you misunderstood me. I'm not saying that there should be no form of authentication, i think it's feasible to facilitate a proxy for authentication (See https://github.com/tmsmr/xmpp-webhook/issues/22).
Using unguessable URL's for the endpoints would either require a more complex configuration or would make the webhook stateful (which i kind of don't want).
Since authentication for the webhook was requested several times, i am considering adding it!