node-slack-sdk: Cannot start rtm client by providing valid xoxb token, the error shown `not_allowed_token_type`
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:
- use rtm sample code and provide valid
xoxbtoken - run the code and display
not_allowed_token_typethere is no documentation aboutnot_allowed_token_typeerror
Expected result:
rtm client should connected
Actual result:
[INFO] RTMClient:1 unable to RTM start: An API error occurred: not_allowed_token_type
Attachments:
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 34 (11 by maintainers)
For others ending up in this thread trying to find how to create a classic app with
botscope because of wanting access to RTM: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 theoauth.accessmethod to exchange the code, client ID, and client secret for an access token. Be careful not to useoauth.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 thescopequery parameter includesbot, 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 thescopeparameter. Also notice that this URL does not containv2, which would create a new granular permission installation. Substitute your own client ID into the URL in place ofxxx.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
xoxbtoken you receive will likely be the same as it was before, but you shouldn’t rely on what the app configuration shows you.What a shitshow.
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…
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
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?
Hello awesome folks from slack!! With RTM deprecated what is the alternative for the below usecase?
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.
To clarify a few things and (hopefully) address a few of the pain points expressed in this issue:
rtm.startcall, 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 inrtm.startcan be fetched using Web API methods likeusers.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)
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”
@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.
ok, can we have
bot.rtmscope then? The scope that will work only for RTM.Don’t click on this!
because there is no
botscope that is required for RTM 😦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?
You can create a GBP app from https://api.slack.com/apps?new_granular_bot_app=1
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
botscope, 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
botscope. 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=1If this doesn’t fix your problem, let me know and I can look into it further.
It’s hard to know wether we can use a user token (xoxp) for the RTM API. I’ve tried, I get an error:
Using an RTM API is hard because of connevectivity issues. Any thoughts?
@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.
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!
It seems like they re-released this as “Socket Mode”
https://medium.com/slack-developer-blog/socket-to-me-3d122f96d955
Hey @confiq,
Granular bot permissions is a solution for apps which don’t need all the access granted by the
botscope 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
botscope is roughly equivalent to the sum of its individual granular scopes (actually, there are granular scopes which can add new capabilities). Allowing the broadbotscope 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 thebotscope, 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.
@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.