Right now outgoing webhooks are unavailable in private channels. Quoting @it33:
it was done for privacy concerns–if you have a public channel, the expectation is that you’re okay with anyone reading its contents, so public webhooks are okay.
If you have a private channel, your expectation as a user is that you decide who reads it. If someone adds an outgoing webhook, then someone you didn’t add to the private group can read its contents–which seems “unobvious” and so we didn’t offer outgoing webhooks in private groups. Bots appear as users within private groups, so the user is aware they’re listening, so that is okay.
Now a user may run a bot using her own account, so that the other participants wouldn’t be able to tell if a bot is present. One could imagine preventing API access to a private channel, but even this won’t prevent old-fashioned copy-paste.
I propose to re-enable outgoing webhooks from private channels for the users that are present in the channel.
As a bonus proposal, I suggest to closer match the format of incoming and outgoing webhooks. For some reason an outgoing webhook expects a JSON entry username, while the outgoing webhook providesuser_name. Making these two formats identical would go a long way towards mattermost federation. Likewise adding an icon_url entry to the outgoing webhook.
Since we’re discussing webhooks, looking at the hook definition, I realize there’s also no information provided about the displayed username, nor if it is a reply to a previous message.
I think if we enabled outgoing webhooks into private groups ideally there would be an easy way for users to see what’s been added.
E.g. an indicator in the member’s list of a private group that indicates what integrations (e.g. outgoing webhooks, and what keywords they’re listening for) are “members” of the channel, the same way end users would get an indication that a bot was part of the channel.
Our design principle is “fast, obvious, forgiving” and having outgoing webhooks in a private group with not indication to group members seems non-obvious that conversations could be monitored (versus public channels, where the expectation is that conversations are more open).
I think eventually we can add this, it just needs the right UI.
I think if we enabled outgoing webhooks into private groups ideally there would be an easy way for users to see what’s been added.
But why? There is no way to tell if a user participating in the private channel scrapes the data on her own, and there is never going to be such a way: the user may even use a webdriver and not touch the API. What additional guarantees would infomation about webhooks provide? Ultimately a private channel means trust to all participants, and it cannot be resolved on software side. I think seeing that someone else may read this information is already an obvious indication that this someone else can relay this information somewhere else. Fast, and obvious.
The only important thing I can think about is disabling the webhook once its creator leaves the channel.
I’d like to migrate from Gitter to MM 3.8.2, including one private chat room - but it looks like I can’t make an outgoing webhook for private use, as this thread indicates? FWIW, I’m trying to use the Matterbridge project for this…
Are there ways to get around this limitation, or am I going about this the wrong way?
@jcw Outgoing webhooks aren’t yet supported in private channels. As mentioned above, we’ll need to consider the right UI for it to follow the “fast, obvious, forigiving” principle.
However, if you need something that works in a private channel, I suggest considering to use a slash command, which work across channels.
Has there been any progress with this during the last two years? Obviously no?
I assume most companies don’t use private channels for actual privacy reasons, but just for not showing their team/project channels in the channel list for anyone to join. It should be at least a configurable option to allow outgoing webhooks from private channels.
Slash commands obviously format requests in a different way which may not work with all external systems. Also, it’s not logical for the users that some commands work only on some channels.
Well, I ended up solving the problem in a different, ugly way.
The problem with external systems is that Microsoft Flow (or Power Automate nowadays) drops all webhook trigger requests which have an Authorization HTTP header in them. That’s a non-configurable behaviour, and Mattermost send the Authorization header in slash command requests.
The workaround? I wrote a small Powershell script running as a serverless Azure Function, which only receives the Mattermost webhook requests, strips out the authorization header and formats the request as JSON forwarding it to Flow for processing. Works fine, although is slightly ugly.
