When using hubot-slack with a standalone Slack application (instead of a Hubot configuration) the wrong token is used for the web api client

[hparadiz]

• I've read and understood the Contributing guidelines and have done my best effort to follow them.
• I've read and agree to the Code of Conduct.
• I've searched for any related issues and avoided creating a duplicate issue.

Description

When using hubot-slack with a standalone Slack application (instead of a Hubot configuration) the same token is used for instantiating the web API client object as is used to connect to the RTM API for the bot.

Stand alone Slack applications provide two OAuth access tokens. One is for the bot user xoxb- and only has API access for identify,bot:basic via the web API. Thus most API calls return the error: missing_scope.

Reproducible in:

{project_name} version: current
OS version(s): any
Device(s): any

Steps to reproduce:

1. Visit https://api.slack.com/
2. Click Build & Make a new Application
3. Enabled bot users
4. Go to OAuth & Permissions and copy the Bot User OAuth Access Token to use as your HUBOT_SLACK_TOKEN environmental variable.
5. Attempt an API call via robot.adapter.client.web. Try: channels.history, groups.history, or emoji.list

Expected result:

Successful call via web API

Actual result:

error: missing_scope

Recommended fix:

The web API should be using the OAuth Access Token instead of the Bot User OAuth Access Token shown below:

Please provide a secondary environmental variable for the Web API client which can be used to override the default.

[aoberoi]

Hi @hparadiz!

The current implementation assumes you will use one token in your hubot application (handled by the SlackClient class). Typically, we suggest using the Bot User OAuth Access Token (xoxb-...), since that includes bot scope, which is a "super-scope" that includes all the scopes listed in the bot user documentation. note that there are different scopes depending on whether the bot user is part of an App or part of a Custom Integration. this scope provides all the most common functionality users of Hubot require, but you are right that it doesn't include the *.history scopes from inside an App.

The *.history scopes are the most sensitive for most teams: it allows programmatic access to the entire message history! This means teams are less likely to authorize an App for installation in their workspace if it is requesting this scope.

Some features of the platform are only available to Apps (Events API, Interactive Messages, and most significantly Distribution). If you are interested in using the platform in any of these ways, my recommendation is still initialize this Slack adapter with the bot user access token, but in your own scripts initialize a new WebClient instance (from node-slack-sdk) with your App's OAuth Access Token (xoxp-...) and to use that for any methods where you need a scope that isn't included with your bot scope.

But if you are only developing for your own team, then using a Custom Integration bot would be the quickest way to resolve your issue. If you one day envision yourself needing the capabilities of Apps described above, it might still be wise to follow the recommendation above.

Thanks for pointing out this difference, I hadn't thought about it carefully previously. This will be necessary to keep in mind when working on #418.

if you feel really strongly that this adapter should support arbitrary scopes into its functionality, then we can change this issue to a enhancement. otherwise i think this was a really great question and i'm closing it since i've answered. feel free to reply.

[rayterrill]

@aoberoi - so does this mean that the OAUTH permission would execute under the context of the approving user? I just tested this out, and that's what appears to happen (I approved the app with channels.create permission, and when I got hubot to create a channel it looked like I created the channel vs hubot).

[aoberoi]

@rayterrill that's correct, thanks for pointing that out. at slack we refer to xoxp tokens as "user tokens" and xoxb as "bot tokens".

bots aren't allowed to create channels. in fact, they can't even join a channel without being invited. and once a bot has joined a channel, it can't leave on its own without being kicked by a user.

when you install a bot user on your team, the authorization step (when you are asked to click "Authorize") is you basically vouching for the app that created the bot user and allowing it to behave as you according to the scopes its requested. you should only click "Authorize" if you feel comfortable with that.

[rayterrill]

Got it. I don't love it, but I understand, and it's working for us now.

I do wish there we had the ability to select which permissions we were comfortable with the bot having in our tenant, as opposed to a hardcoded set of permissions that are possible for bot accounts. Also hoping the new token system that's coming soon helps with some of this, potentially.

[benpbolton]

🤔 I'm not a fan of the current approach splitting out permissions and capabilities based on the type of bot token, particularly when they have mutually exclusive capabilities.

For instance, the hubot docs do warn against using the 'slack app' style bot if you need *.history calls...

Don’t use this choice if your Hubot needs access to any of the permissions that are only available to Custom Bots in the Bot methods documentation

But conversely, a similar warning could be present with the 'Custom Bots':

Don't use this choice if your Hubot needs access to any of the interaction (buttons) capabilities that are only available to a Slack App with a Bot User

We're going to need to follow this approach from @aoberoi :

my recommendation is still initialize this Slack adapter with the bot user access token, but in your own scripts initialize a new WebClient instance (from node-slack-sdk) with your App's OAuth Access Token (xoxp-...) and to use that for any methods where you need a scope that isn't included with your bot scope

... which feels a bit like a sad complexity.

[rayterrill]

Totally agree with @benpbolton.

I would personally love a token implementation that's technically separate from any permissions structure, with the ability for us to set permissions on the token as we see fit (as opposed to token types dictating possible permissions). This would fit a lot better with the other systems we're integrating with - Github, Azure, AWS, etc.

[benpbolton]

@rayterrill I'm embarrassed to only have found this (third) (developer-preview) option recently: https://api.slack.com/docs/working-with-workspace-tokens

I'm unsure if it'll fit your use-case, but it seems possible (privilege escalations, per-channel perms, etc)

[rayterrill]

Thanks @benpbolton. I'm pretty sure the workspace tokens was something @aoberoi talked about previously. Do you know if it's compatible with Hubot, or what the limitations are?

[aoberoi]

Hey folks. Unfortunately, workspace tokens will not be a way forward for the Hubot project, since Hubot is running on RTM and workspace apps will not support RTM.

Our team is currently exploring other options to bridge the same functionality to Hubot apps with minimal changes. We’re not ready to publicly release anything but I’m actively looking for Hubot users who would like to pilot experimental solutions and give the team their feedback. If you think this would be right for you, let’s have a conversation about your team and the ideas we’re trying to vet! Contact me by DM in Bot Developer Hangout (dev4slack) or by email (ankur@slack-corp.com)

[aoberoi]

@benpbolton your point about the warning is well made. The reason I hadn’t added it earlier is because that could be interpreted as an advertisement that interactive components (such as buttons) are supported in Hubot as a Slack App. I’m purposely trying not to give that impression, since making that work involves very specific work to enable incoming connections. This can work but it’s been left as an exercise to the motivated and informed developer, since we cannot offer a reasonably simple and widely applicable solution. Do you think the documentation mislead you to believe interactive components are a supported platform feature?

[benpbolton]

Thanks for providing some of the rationale for the documentation @aoberoi! As is typically the case of an implementor, we tend to be myopic for our own use-cases... so while I'll set out the challenges we faced when attempting to implement interactive messages/dialogues that could be experienced by others, it doesn't necessarily mean they were as impacted as we were.

We treat our hubot bot/app like a user (who might take over the world): one channel invitation means it's been granted all the permissions required to interact with the channel (or group). Here was our path:

1. Traditional hubot xoxb tokens aren't allowed to post interactive attachments (is this due to the slack web-based interface requiring specifying the postback and verification tokens? this challenge doesn't seem insurmountable: bot payload could provide the postback/verification token/callback_id on post)... regardless, now we needed to create a 'slack app'

2. Traditional slack apps allow a bot user (hurrah!!) but those bots have a reduced permissions set in those channels (boo!!). We were willing to toss out the old bot token and reinvite to all of our channels, but some of our functionality relied on ye-olde (groups|channels|conversations).history... so we wired up history calls to use the oauth token. Unfortunately our bot currently has access to private channels (groups) that the installing (oauth) user did not have access to. So after some experimentation, there was simply no trivial way to maintain a single hubot instance extended with the oauth dance for multiple users just to maintain our existing functionality and permissions sets. While it should be possible to store independent configurations and oauth tokens for various users who have installed an app configuration, that way seemed to lead to madness.

3. So on we moved to workspace apps: keep our 'old' bot token for channel/chat interactions (including the needed .history endpoints) and extend hubot with https://github.com/slackapi/node-slack-sdk and a workspace token. This will work well-enough for us, and the only price we pay is the single extended complexity of using the workspace tokens when we're posting interactive messages (see Hubot doesn't show up in user list #1). Hubot catches the posts, with a:

  robot.router.post "/hubot/interactions", (req, res) ->

...filters the validation token and callback_id, and is generally able to do everything we need it to do. (With one exception: xoxa tokens seem unable to hit the conversations.history endpoint: I needed to parse the payload or channel name for groups|channels.history)

All that to say: interactive components perhaps ought to be a supported platform feature :) Allowing traditional bot tokens to post interactive components would've been the most intuitive step for us. Then again, perhaps this is us: https://twitter.com/jakewrfoster/status/1010903052067442688