Prevent Slack from unfurling anything for login-required sites


(Dave McClure) #1

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:

I end up clicking the ‘x’ on that attachment every time…

Is there something simple we can do to prevent this attachment from getting added in the first place?

Should login-required sites just get the metadata that Slack requires to generate that attachment redacted by default?


(Jeff Atwood) #2

You can tell Slack to permanently stop unfurling any links from that domain. Why is this being reported here when it is a Slack question?


(Dave McClure) #3

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

Thanks!


(David Taylor) #4

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.


(Dave McClure) #5

I wonder if that’s new. I asked Slack about this a while back and I don’t think they had this option back then.

I’ll check it out!

Do you think it’d make sense to keep this as a separate plugin or integrate it into the chat-integration plugin?


(David Taylor) #6

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.