Skip to content

Design: Unfurl private GitLab links shared in Slack workspace

This issue is the design spec for handling private link unfurling.

Unfurl behavior

An ideal way to handle authenticated link unfurls would be for the GitLab Slack application to do a "lookup" of every Slack user in a channel to understand what permission each Slack user has in GitLab before unfurling a link preview to them. This way

However this is not technically possible with how Slack handles authenticated unfurls in channels (https://api.slack.com/reference/messaging/link-unfurling#tips).

Everyone in a channel can see your app's unfurls. Using authenticated unfurls only requires authentication to unfurl, but still broadcasts those unfurls to a conversation.

Proposal

graph LR
    A[In Slack, a user<br>posts GitLab link] --> Z[GitLab receives<br>event]
    Z --> D{Is link to<br>a private/confidential<br>object?}
    D -->|No| E[Unfurl link]
    D -->|Yes| K{Does the integration setting allow<br>unfurling private/confidential links?}
    K -->|Yes| E
    K -->|No| G[Do nothing]
  • By default, we unfurl all links that are public.
  • We only unfurl links that are private (or confidential) if the integration admin has enabled the Slack integration for the project/group and checked a box saying "unfurl private/confidential links". Note This check should be scoped to the Slack workspace ID and the Integration, so that another Slack workspace cannot unfurl the private links.
  • We should include the option to Disable all link unfurls.
  • If "Unfurl private/confidential links" is enabled, we display a warning that communicates the potential risks.

See also:

backend implementation issue: #358683.

Resources

Questions

  • There can be a slight difference between the permissions of who can see an issue in a private project vs a confidential issue.
  • Problem validation: Does it make sense to create a separate configuration option for confidential links?
Edited by Libor Vanc
OSZAR »