# Prevent Slack from unfurling anything for login-required sites
**URL:** https://meta.discourse.org/t/prevent-slack-from-unfurling-anything-for-login-required-sites/75233
**Category:** Support
**Created:** [12월 2, 2017, 12:52오후 UTC](https://meta.discourse.org/t/prevent-slack-from-unfurling-anything-for-login-required-sites/75233 "2017-12-02T12:52:40Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@mcwumbly](https://meta.discourse.org/u/mcwumbly)
#### Post date: [12월 2, 2017, 12:52오후 UTC](https://meta.discourse.org/t/prevent-slack-from-unfurling-anything-for-login-required-sites/75233/1 "2017-12-02T12:52:40Z")
Our Discourse instance is private and we use the [discourse-slackdoor](https://meta.discourse.org/t/discourse-slackdoor-plugin/44632) 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?
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [12월 2, 2017, 9:02오후 UTC](https://meta.discourse.org/t/prevent-slack-from-unfurling-anything-for-login-required-sites/75233/2 "2017-12-02T21:02:32Z")
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?
---
### Author:  [@mcwumbly](https://meta.discourse.org/u/mcwumbly)
#### Post date: [12월 2, 2017, 9:07오후 UTC](https://meta.discourse.org/t/prevent-slack-from-unfurling-anything-for-login-required-sites/75233/3 "2017-12-02T21:07:30Z")
> [@codinghorror](#):
>
> Why is this being reported here when it is a Slack question?
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.
> [@codinghorror](#):
>
> You can tell Slack to permanently stop unfurling any links from that domain.
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](https://get.slack.help/hc/en-us/articles/204399343-Share-links-in-Slack#turn-off-link-previews-for-specific-sites)
Thanks!
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [12월 2, 2017, 9:16오후 UTC](https://meta.discourse.org/t/prevent-slack-from-unfurling-anything-for-login-required-sites/75233/4 "2017-12-02T21:16:38Z")
I’m not sure if you’re already aware of this option - apologies if so.
> [@Discourse Slackdoor Plugin](https://meta.discourse.org/t/discourse-slackdoor-plugin/44632/1):
>
> When you post a message that starts with a link to a post or a topic in your private Discourse instance, a bot will post a message that contains the unfurled content as a reply.
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.
> **[Unfurling links in messages | Slack Developer Docs](https://docs.slack.dev/messaging/unfurling-links-in-messages/)**
>
> When users post messages in Slack containing links, we attach previews, adding context and continuity to conversations. Three facets of link unfurling exist:
---
### Author:  [@mcwumbly](https://meta.discourse.org/u/mcwumbly)
#### Post date: [12월 2, 2017, 9:19오후 UTC](https://meta.discourse.org/t/prevent-slack-from-unfurling-anything-for-login-required-sites/75233/5 "2017-12-02T21:19:50Z")
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?
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [12월 2, 2017, 9:25오후 UTC](https://meta.discourse.org/t/prevent-slack-from-unfurling-anything-for-login-required-sites/75233/6 "2017-12-02T21:25:18Z")
The [changelog](https://api.slack.com/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.
---
### Author:  [@system](https://meta.discourse.org/u/system)
#### Post date: [1월 31, 2020, 7:16오후 UTC](https://meta.discourse.org/t/prevent-slack-from-unfurling-anything-for-login-required-sites/75233/7 "2020-01-31T19:16:25Z")
---
### Author:  [@system](https://meta.discourse.org/u/system)
#### Post date: [12월 22, 2023, 9:20오후 UTC](https://meta.discourse.org/t/prevent-slack-from-unfurling-anything-for-login-required-sites/75233/8 "2023-12-22T21:20:24Z")
---
### Author:  [@JammyDodger](https://meta.discourse.org/u/JammyDodger)
#### Post date: [12월 23, 2023, 9:09오전 UTC](https://meta.discourse.org/t/prevent-slack-from-unfurling-anything-for-login-required-sites/75233/9 "2023-12-23T09:09:06Z")