Cannot start rtm client by providing valid xoxb token, the error shown not_allowed_token_type

[zhang699]

Description

Cannot star rtm client by providing valid xoxb token shown not_allowed_token_type error
use sample code

Am I missing something ?

I'm sure I am using a bot user token (xoxb), not a user token and the token can push message as bot to specific channel

const { RTMClient } = require("@slack/rtm-api");
import config from "../config";
// An access token (from your Slack app or custom integration - usually xoxb)
const token = config.SLACK_BOT_USER_AUTH_TOKEN;

// The client is initialized and then started to get an active connection to the platform
const rtm = new RTMClient(token);
rtm.start().catch(console.error);

// Calling `rtm.on(eventName, eventHandler)` allows you to handle events (see: https://api.slack.com/events)
// When the connection is active, the 'ready' event will be triggered
rtm.on("ready", async () => {
  // Sending a message requires a channel ID, a DM ID, an MPDM ID, or a group ID
  // The following value is used as an example
  const conversationId = "C1232456";

  // The RTM client can send simple string messages
  const res = await rtm.sendMessage("Hello there", conversationId);

  // `res` contains information about the sent message
  console.log("Message sent: ", res.ts);
});

// After the connection is open, your app will start receiving other events.
rtm.on("user_typing", event => {
  // The argument is the event as shown in the reference docs.
  // For example, https://api.slack.com/events/user_typing
  console.log(event);
});

What type of issue is this? (place an x in one of the [ ])

• bug
• enhancement (feature request)
• question
• documentation related
• testing related
• discussion

Requirements (place an x in each of the [ ])

• 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.

Packages:

Select all that apply:

• @slack/web-api
• @slack/events-api
• @slack/interactive-messages
• @slack/rtm-api
• @slack/webhooks
• I don't know

Reproducible in:

package version: 5.0.3

node version: 10.15.3

OS version(s): MAC Mojave

Steps to reproduce:

1. use rtm sample code and provide valid xoxb token
2. run the code and display not_allowed_token_type there is no documentation about not_allowed_token_type error

Expected result:

rtm client should connected

Actual result:

[INFO] RTMClient:1 unable to RTM start: An API error occurred: not_allowed_token_type

Attachments:

[shaydewael]

EDIT: I just saw your screenshot so I see that you're app is in fact granular bot permissions instead of a regular app 😓Only the second part of this comment is relevant for you

@zhang699 Hey there 👋 I found one possible problem, but this may be a little confusing (sorry in advance 😅).

When I created a regular Slack app, this code worked fine for me and I didn't get any errors. "Regular" Slack apps, in this case, are apps that do not use granular bot permissions. To tell if your app uses granular bot permissions you can go to the App Management, click on your app, then OAuth & Permissions on the sidebar. If your app has a bot scope, it's probably a regular app. Something like this:

~

However, my guess is that your app is using a granular bot permissions app. I was able to reproduce the error using this token. If your app uses granular bot permissions, the OAuth & Permissions page will look like this instead:

Unfortunately, granular bot permissions apps do not support the RTM API, since it requires the bot scope. Instead, you can use the Events API to receive most events. If you need to use the RTM API for whatever reason you should create a regular Slack app (this is the default way Slack apps are created): https://api.slack.com/apps?new_app=1

If this doesn't fix your problem, let me know and I can look into it further.

[zhang699]

thanks @shaydewael :) , it fixed my problem, I have recreated the app, the bot scope appeared. and the bot scope cannot be removed.

I don't know how was I create granular bot permissions slack app that produce this problem.

could you give me steps to create granular bot permissions app?

[seratch]

I don't know how was I create granular bot permissions slack app that produce this problem.
could you give me steps to create granular bot permissions app?

You can create a GBP app from https://api.slack.com/apps?new_granular_bot_app=1

[zisadlier]

I had an app that had the bot scope, and then I changed the permissions and must have changed it to use granular permissions. How do I revert it back to using just the bot scope without creating a new app so I can use the RTM API again?

[confiq]

I'm in same boat as @zisadlier ^

EDIT: Talked with slack support, you can't change the app to be classic!

[confiq]

Don't click on this!

because there is no bot scope that is required for RTM :(

[aoberoi]

In general @confiq is right. Don't update scopes for an app that is using RTM, it will make your app stop working. If you accidentally update scopes, the recommended path forward is to update your app to use the Events API. We acknowledge that in some cases updating to use the Events API is impossible or impractical since that requires your app to be reachable via a public URL. In these cases, read on.

There is a way to convert your installation back. It's complicated, and will make managing your app much harder in the future, so don't go down this route unless its necessary. If you have many users already using your app, so creating a new app isn't an option, then this conversion back to a regular app likely makes sense.

In order to convert your app back to a regular Slack app, you need to first configure OAuth. In the app configuration, choose the "OAuth & Permissions" page. If you haven't already, add a "Redirect URL". If you cannot create a public URL for your app, you can use a "localhost" URL for OAuth purposes. For example, you can set the Redirect URL to http://localhost:3000/auth/slack.

Next, you need to add code in your app to handle the OAuth redirect. Please read the OAuth documentation to understand how the OAuth flow works. Following the example above, you'll need to start an HTTP server on port 3000, which handles requests to the path /auth/slack, where the handler calls the oauth.access method to exchange the code, client ID, and client secret for an access token. Be careful not to use oauth.v2.access - that would create a new granular permission installation.

Then, you'll need to visit the installation URL for your app. Typically this is done by clicking the "Add to Slack" button created for your app. As a shortcut, if you know which scopes your app needs and your client ID, you can create the URL yourself. Following the example, we would use https://slack.com/oauth/authorize?scope=bot&client_id=xxx.yyy. Notice that the scope query parameter includes bot, which is a scope for regular Slack apps but not for granular Slack apps. If your app uses other scopes, you would use a comma-separated list of them as the value for the scope parameter. Also notice that this URL does not contain v2, which would create a new granular permission installation. Substitute your own client ID into the URL in place of xxx.yyy. Once you've created this URL, visit it in a browser.

Now you should see Slack asking you permission to install the app in your workspace. Make sure its the right workspace and use the toggle in the upper right side of the screen if it isn't. Once you authorize the installation, the browser will redirect to the OAuth Redirect URL you set previously, which your app will handle by calling oauth.access, and then the installation will be complete. You've now converted your app back to a regular Slack app.

However, when you use the Slack app configuration pages you will continue to see the updated scopes, which will be incorrect. If you ever need to update the scopes, you'll have to build a new installation URL manually, visit it, and finish the installation as shown above. The xoxb token you receive will likely be the same as it was before, but you shouldn't rely on what the app configuration shows you.

[aoberoi]

I think we've gotten to the bottom of this issue, so I'm going to close. We can do a better job documenting the cases that got brought up here, so I created the issue above to track that work. Feel free to comment if this or a related concern comes up again!

[ChrisDoohan]

If the RTM API will no longer be usable on new apps, would it be possible to put a deprecation notice on this documentation? As is, it is very misleading.
https://api.slack.com/rtm

[confiq]

Do you have a specific reason why slack would you deprecate RTM API?

[stevengill]

@ChrisDoohan we haven't officially deprecated RTM. We do want app developers to be using the events api over RTM, but RTM still handles some use cases that events api doesn't (mainly working behind strict corporate firewall policies)

At the bottom of the page you link, it includes a Create a Classic Slack APP section that allows you to create an app that works with RTM.

[KeesCBakker]

Just upgraded and my app died. I really think you should have a better notice about the consequence of upgrading!! This user xp is bad...

[amilbourne]

@stevengill I'm struggling to find any info on the future of the RTM API. You say it isn't being deprecated, but the new GBP model doesn't support it, and only GBP based apps will be allowed from the 21st of Feb. Since the Events API doesn't provide some of the functionality in the RTM API, it looks like my app is about to fall off a cliff.

[stevengill]

Hey @amilbourne, it sounds like existing RTM apps that are already on the App Directory can continue publishing until Dec 1st, 2020. If you’re not distributing to the App Directory, like for a custom app just in your organization, the deadline doesn’t apply.

Would it be possible for you to share which features of RTM you are using that aren't available in with the Events API currently?

[stevengill]

@KeesCBakker I totally understand and empathize with your issue. I've gone ahead and shared this thread with the team in charge of the api site so they can take a closer look at the existing experience on the upgrading flow.

[confiq]

Can we know the technical reason why there is no bot scope in new GBP based apps?
It sounds trivial but I guess it's very complicated.

[stevengill]

Hey @confiq,

Granular bot permissions is a solution for apps which don’t need all the access granted by the bot scope and can provide more safety to the app’s users by operating on a principle of least privilege. Some users (and admins) refuse to install apps that request a broad level of access without a warranted reason, and that’s totally reasonable. GBP gives app developers a means to offer those users a set of scopes they are more willing to install.

There are some other benefits of shifting API usage from user tokens to bot tokens: it allows developers to manage fewer, non-redundant bot tokens; bot users remain in the team after the initial installing user leaves which is better for continuity.

From a purely technical point of view, the bot scope is roughly equivalent to the sum of its individual granular scopes (actually, there are granular scopes which can add new capabilities). Allowing the broad bot scope to be requested alongside its parts would create complex situations, due to the overlap in permissions, for management of apps. For example: if an admin revoked the bot scope, should all of its parts also be revoked? It also doesn’t serve the needs described above.

Are you building an app that will be distributed on the App Directory and currently using RTM? If so, let’s chat directly so I can understand your needs and use case a little better. If not, you should be able to continue to use a classic app for the foreseeable future. You can find me (steve gill) on the community workspace in the #slack-api channel.

[amilbourne]

@stevengill I could rewrite the app in the events API at a push but RTM provides some stuff that makes it much easier to use. The primary feature is that messages arrive in order. It is also useful that it uses an outgoing connection which side-steps issues with corporate firewalls.

The feeling I'm getting at the moment is that Slack didn't realise that there would be a problem with the RTM API, and are now trying to decide what to do about it. Hence lots of mixed messages on ts future.

[stevengill]

@amilbourne I believe even for RTM, messages don't arrive in order.

Slack was aware that RTM would not be supported by Granular permissions. It is referenced in our migration guide

[johnkors]

For others ending up in this thread trying to find how to create a classic app with bot scope because of wanting access to RTM:

• Direct link to create a classic app :https://api.slack.com/apps?new_classic_app=1
• Source of link is aaaaaaaaall down the end of this wall of text of a doc: https://api.slack.com/rtm (if any Slack employees see this, please make this easier to find, or better: make it available as a choice in the modal where you create a new app)

[confiq]

Hey @confiq,

From a purely technical point of view, the bot scope is roughly equivalent to the sum of its individual granular scopes (actually, there are granular scopes which can add new capabilities). Allowing the broad bot scope to be requested alongside its parts would create complex situations, due to the overlap in permissions, for management of apps. For example: if an admin revoked the bot scope, should all of its parts also be revoked? It also doesn’t serve the needs described above.

ok, can we have bot.rtm scope then? The scope that will work only for RTM.

[DannyHinshaw]

So which is it? Are we able to continue using rtm or is this going to force us all into using granular permissions which don't allow for it?

Gotta say, I used to write Slack integrations a lot and this process has become completely convoluted, confusing and just a general PIA. Is this intentional?

[ghost]

Link to a blog post they provided about the update: https://medium.com/slack-developer-blog/more-precision-less-restrictions-a3550006f9c3

[penguinpowernz]

This "Events API" is terrible. Is there a new websockets endpoint available rather than having to host a freaking web server in order to receive events?!

Slack: "Don't call us, we'll call you"

[badrbouslikhin]

It's hard to know wether we can use a user token (xoxp) for the RTM API. I've tried, I get an error:

The server responded with: {'ok': False, 'error': 'missing_scope', 'needed': 'rtm:stream', 'provided': 'identify,bot,channels:history,channels:read,reactions:read'}

Using an RTM API is hard because of connevectivity issues.
Any thoughts?

[khanhtc1202]

@MrZeroo00, got the same problem with RTMClient, I'm using a user token (xoxp) under 'channels:read' scope only. Is this issue closed so there will be no update if we wait here?

[seratch]

@khanhtc1202
Unfortunately, there is no way to use RTMClient with a user token (xoxp-). Consider using a "classic" bot and use a bot token for your RTM app.

To set up a new app, follow the instruction at https://slack.dev/node-slack-sdk/rtm-api

If you need to use RTM (possibly due to corporate firewall limitations), you can do so by creating a legacy scoped app. If you have an existing RTM app, do not update its scopes as it will be updated to a modern scoped app and stop working with RTM.

[usubram]

Hello awesome folks from slack!! With RTM deprecated what is the alternative for the below usecase?

• With Event a bot solution is forced to go to public
• The data being fed to the bot is not public for events api to access.
• Not all usecase in the organization requires distributed apps.
• There is no way in Web api to push a message to bot and receive response back.

i'm wondering why slack had to deprecate a way which would completely block a way of working with a bot and want everyone to deal with exposing their apis casing security concerns, firewall.

[whitehat0917]

@confiq I used "update your apps scopes", so my slack app is not working before was good.
How can I go back before status?

[confiq]

@whitehat0917 I'm not working for slack but from my understanding, the only good solution is to create a new classic app as mentioned before on this thread.

However, slack encourage you to use event API instead of RTM for now. So if you can do it, follow it

[tm604]

Seems that RTM and all other APIs are going to be dropped entirely in favour of the conversations API:

https://api.slack.com/docs/conversations-api

which is a major step backwards if true.

[leetrout]

It seems like they re-released this as "Socket Mode"

https://medium.com/slack-developer-blog/socket-to-me-3d122f96d955

[supermarin]

What a shitshow.

[shaydewael]

To clarify a few things and (hopefully) address a few of the pain points expressed in this issue:

• Socket Mode was released this year as an evolution of the RTM API. It uses a WebSocket connection and retains the primary use cases for RTM (securely building Slack apps without needing a public HTTP endpoint being a big one) but also allows apps to use interactive features and surfaces, workflow steps from apps, and events only available on the Events API (like when an app is directly mentioned). It also guarantees events in the correct order, which RTM could not do.
• There aren't immediate plans to deprecate the RTM API, but Socket Mode is its replacement so it may happen at some point in the future. In the case of any deprecation there will be a lot of explicit communication leading up to it. While you can still create Slack apps as mentioned above, we really don't recommend it if at all possible. But if you need to use RTM for the time being, it remains usable.
• One of the discrepancies right now is the rtm.start call, which was created at the beginning of the platform and grants your app a lot of information about the workspace, most of which apps don't use. This didn't scale well to larger enterprise orgs (sends apps an overwhelming amount of data), and also introduced security concerns around the amount of information that apps had within a workspace without the knowledge of admins. Nearly all of the information present in rtm.start can be fetched using Web API methods like users.list, conversations.list, etc. with their corresponding scopes.

Apologies if this seems insufficient—the team building Socket Mode is very much trying to address nearly all of RTM's use cases before thinking of deprecation so that apps can build with newer (most of the core features released after 2016) and to-be-released features that expand what they can do without pulling out the rug from under anyone.

(And in case anyone is looking for it: the migration guide to the granular token model)