Users and Roles

[geowa4]

Authentication is technically handled by Slack, but we need a way to authorize those users to run certain commands. Using the verb-noun pair, we can authorize roles to run commands by either verb, noun, or both.

Assume an "EventManagement" role and skills list-event, show-event, and create-event. If that role has access to all commands whose noun is "event", users in that role can run all three. Another role "EventReader" that has access to "list" and "show" verbs on "event" could run the first two but not create-event.

[dantswain]

One potentially tricky thing here is I think that a user is allowed to change their username and there don't appear to be many restrictions on this other than a rate limit.

The community seems to suggest using a combination of team id and slack id (not name) in this kind of situation, but I can't find any documentation on guarantees that user ids will be consistent and not be reused. I've submitted a help request to Slack asking for clarification.

User object documentation: https://api.slack.com/types/user

[dantswain]

@geowa4 How do you imagine that these roles will be defined? Spitballing options:

• Server-side flat file configuration - by far the simplest thing to implement but not very manageable. Gets complicated due to handling slack user ids - the admin would have to do an API lookup to determine the user id for a given user.
• Web admin portal - Shouldn't be too hard to implement something rough here, but could be tough to implement a "good" design. It would be feasible to start with something rough and refine it in future iterations.
• Slack-based interactive configuration - I.e., the admin uses slack commands to administer the bot. Doesn't require web front-end work, but could be complicated to work out the command sequences and handle all of the edge cases wrt input errors and whatnot. It seems like you would have to get a lot of this right on the first iteration, so it might require more up-front development time. It could be added in a future iteration as a convenience to supplement a web-based admin portal.

After writing that out, it seems like a web portal is probably the way to go at least at first, but maybe there are other ideas?

There's also a bootstrapping problem here. When the bot first boots up and "discovers" a slack team, how does it associate slack usernames with user ids? Perhaps the admin enters their username in the web ui, which initiates the bot sending the user a DM which must be responded to with a passphrase that is displayed on the web side?

[dantswain]

Got clarification from Slack (kudos to them for being responsive and helpful!): Within the scope of a team, a user id is never reused or reassigned. So, we should be safe scoping permissions to a combination of team id and user id.

[geowa4]

We can provide a list of usernames in a config file at boot. Then, we can make a Web API (https://api.slack.com/methods/users.list) request to list all users in the channel to get their IDs.

[dantswain]

That list would have to be ephemeral. The user is allowed to change their username at any time.

[geowa4]

Yeah, if there's persisted data (however we end up storing that between possible restarts) then ignore that list.