Make invites UX more transparent (URL and UI)

[riedel]

Summary

We had multiple "security incidents" due to people inviting other people into the wrong teams

Steps to reproduce

If you invite people only the title of the team is shown in text. This seems to be to few cues for many users (empirically).

Expected behavior

It would be great if

1. the Team Icon is displayed
2. the Team name is part of the invite URL (may be optional via setting if they need to be short, which they aren't anyways)
3. if the user specific invite codes should trigger clear join messages: "@ X joined the team (invited by @ Y)"

Observed behavior (that appears unintentional)

It happened multiple times on our instance during the last week that people for whatever reason sent the wrong invite codes (new people popping up in teams).

[amyblais]

@riedel What Mattermost server version are you on?

[riedel]

Mattermost Version: 5.20.1

[wiersgallak]

Hello @riedel Thank you for providing this insight on the changes to the invite flow. I have created a ticket for our UX team to review your input and see if there are some additional improvements we can make. Feel free to follow https://mattermost.atlassian.net/browse/MM-24979 for updates on this.

Regarding the security concerns and a potential solution, wondering if adding a domain restriction on each team would be useful for your use case? You can set the domain restriction as a system or team admin under Main Menu > Team Settings > Allow only users with a specific email domain to join this team:
image

[riedel]

thanks alot

Domain restrictions helps a bit, we ended up letting only admins invite and made them aware of implications. Actually the documentation of the domain restriction feature puzzled me a bit: it talked about whitelisting and I could not find documentation about the precedence of rules here (do all requirements need to apply, or is it then public to the people in the whitelist).

To allow other users to extend invites it would actually be in our case needed to scope this to LDAP or SAML groups (maybe an extension for your enterprise editions, which we do not have). As a university research lab in many contracts we have to promise our partners strict confidentiality and need to limit the access strictly to a small defined group that actually needs to know. Auditing access is also really something important in case really our NDAs would be set to trial. I have to admit that we were not prepared for the consequences of "invites". Restricting invites to team admins is already nice (we actually had a huge problem with a broken group admin feature in redmine).

(if anyone of our partners reads this, the incidents mentioned above did not disclose anything since we were lucky :), but we take them seriously and took actions)