The discussion is about preventing Slack from unfurling links from private Discourse instances. mcwumbly is using the discourse-slackdoor plugin to allow Slack to unfurl the contents of posts, but Slack still tries to do its own unfurling. codinghorror suggests telling Slack to permanently stop unfurling links from that domain, and provides a link to do so: Turn off link previews for specific sites.
david proposes using the Slack API’s “Slack App Unfurling” feature to replace Slack’s default unfurling with custom logic, which would allow for more flexibility and security. mcwumbly considers this option and wonders if it would be better to integrate it into the chat-integration plugin or keep it as a separate plugin.
david suggests keeping it separate due to security concerns and different API scopes required. He also notes that the Slack API feature was added in March, making it a relatively recent option.
Our Discourse instance is private and we use the discourse-slackdoor plugin to allow Slack to unfurl the contents of posts that are shared in our private Slack.
But Slack still tries to do it’s own unfurling of the links, which is kind of annoying because all it is able to get is the site title and description.
So every link shared in Slack ends up getting the same, additional attachment from Slack that looks kinda like this:
It’s a Slack<->Discourse question. I am guessing others that use Slack and Discourse might have a similar question, so if we come up with a good answer here, it’ll be helpful to this community.
I didn’t realize that was possible. I’ll have to talk to the folks that administer our Slack workspace and point them to this link: Turn off link previews for specific sites
I’m not sure if you’re already aware of this option - apologies if so.
The Slack API has a section on “Slack App Unfurling”. From a brief read it looks like you can do some clever stuff with the API which replaces slack’s default unfurling for specific links with your own logic. Maybe discourse-slackdoor could be adapted to use this method, rather than the existing “sends a message in response” method?
Using this API would also mean users can put the link anywhere in their message, rather than only at the beginning.
The changelog suggests it was added in March, so yeah fairly recent.
In my opinion it would probably be better to keep it separate. The very nature of it (providing a backdoor to a discourse instance) is a potential security risk if not handled correctly, so it’s probably better that it’s only installed on those instances that really need it.
Also I think the slack API scopes required (links:read and links:write) are completely different to that of chat-integration, so there wouldn’t be much effort saved there by combining them.
