I'm trying to create a bot that people can install in their workspaces and send/receive messages of some sort. The problem I'm running into is the documentation tells you to use the token generated for your workspace:
https://api.slack.com/bot-users#installing-bot
But this makes no sense, seeing as people would be installing the App/Bot on their workspace themselves, it's not like they would be giving me their token or anything. Surely I'm missing something. How am I meant to authenticate a bot against whatever workspace it is installed in a purely API driven way?
There is no "workspace agnostic" Slack token. Every token is linked to a specific workspace and user.
The usual approach is that you provide an installation routine with Oauth 2.0 for your Slack app. When someone installs your app with that routine a new token is created internally that your app needs to collect and store. This is how every Slack app works.
Note that the installation has to be done once only for each workspace. The token does not expire.
Its simply when you install your Slack app on your own workspace only. That can be done directly from the Slack app management window and requires no installation routine. But then you obviously need to manually copy the generated token to your app.
Related
I've got a simple Dialogflowbot that I'm trying to integrate with my Slack workspace.
I've made a Slack app for the bot.
I've added all the information in Dialogflow integration dialog.
On Slack app side I've set-up bot user, added event subscriptions (including link from DF) and set up OAuth scopes and added the URL.
However, the bot won't reply back. Everything looks fine in DF logs but I'm not getting responses in Slack. Previously I've been able to solve this kind of situation by clicking the 'Install to Slack' button under 'Manage distribution' -tab. However, now when I do that (and allow installation), I receive the following error message:
While starting bot the error appears:
Bot start error: oauth_authorization_url_mismatch
From Slack documentation I've found out that this means "The OAuth flow was initiated on an incorrect version of the authorization url. The flow must be initiated via /oauth/authorize." However, the OAuth URL Dialogflow provides is of form bots.dialogflow.com/slack/<TOKEN>/start.
I've
contacted both Slack and Dialogflow support
done bunch of Googling and
asked a few people that also work on Slack bots
but I've found nothing. Maybe someone here would have ran to the same issue would know what to do?
Recently the Slack team made a change in the oauth authentication with backward incompatible changes. This change break the integration with Dialogflow.
Fortunately, the old functionality has not been fully removed from Slack. In the link I shared above (here's again), at the bottom of the documentation there's an option to "Create a classic Slack app". If you click on it, you will be able to create a "legacy" bot and use follow the Dialogflow-Slack integration guide; it will work as intended.
An important thing to notice, is that you'll see an option to "Update Scopes". Be careful not to make this update, as this will change the authentication from classic to the new approach, and it will break the bot.
Finally, the Dialogflow team already knows about this issue and they're working to make the integration compatible with the new Slack authentication. You can subscribe to that IssueTracker (click the star next to the title) and get updates regarding its progress.
I have been making a slack app for the users on my workspace. It is a sidebar that adds slack messaging functionality to our website, so that we don't have to leave the site to see our slack messages. I am having trouble trying to get bearer tokens for each user.
What I have been doing so far is following the Slack OAuth 2.0 Authentication flow in order to receive tokens for users. This worked for me in testing and it works for some of our users currently. However, some users see something completely different.
Instead of asking them for permission to use their slack profile, the slack.com/oauth/authorize is telling them they can't install the app because it isn't listed in the slack directory. However, this page should not be installing the app to the workspace. It is already installed. It should just be asking for their permission to use their profile.
Am I using the wrong page? Did I miss something I need to do?
The Oauth process in Slack is not only used to get an access token, but also always is regarded as installation process for the respective Slack app. So your users are basically (re-) installing your Slack app each time they run through the Slack Oauth process. This is the standard behavior and can not be changed.
If you want to continue using this process you can simple enable installation for your Slack app on the workspace for all users (click on approve on the app management page of your workspace for this particular app) and then your users will no longer get the error message. You may also need to enable distribution of your Slack app on the app management page.
Btw. installing the same Slack app by multiple users is the default approach for getting access tokens for individual users. Slack calls those additional installations "configurations" and you can see them listed on the app ages for your workspace.
Note that Slack access tokens obtained from the Oauth process do not expire. So you only have to let the user install your Slack app once and then store the Slack access token for the next time.
What would be the best way to obtain an AAD token from an electron app?
Microsoft has 2 javascript authentication libraries: adal.js and msal.js.
Both are designed for browsers and not native Electron apps (For example - AAD won't allow for file:/// scheme as a reply URL).
Sounds like a long term solution would be native AAD packages (like Microsoft built for Apache Cordova), but since that's probably not going to happen any time soon, what is the best short-term option?
Azure Storage Explorer is a good example of an Electron app that does this. It even allows for being logged into multiple AAD accounts at the same time.
You might be able to check out what's going on in the app's dev tools. I've had a poke around and it looks like it uses adal-node npm package instead of the browser based js libraries.
It also looks like it uses an authorization code flow for obtaining tokens.
The Azure AD doesn't support the file protocol as the reply address. To develop the single page application, you can host it on the server and using the server URL as the reply address.
let's say I've created slack app and I have client id and secret.
What is the easiest way to get SLACK_APP_TOKEN in my hands that will be able to create channel?
If you want a proper access token that is related to your Slack App the only way to get it is to install your Slack app with the OAuth process as described here in the Slack documentation. You will need a mini website with a script (e.g. PHP) to perform the installation.
The so called test token will also allow you use the Slack API (e.g. to create a channel), provided that the user that created the test token has that right on your Slack. It is the easiest to obtain, but it will always be linked to a user account, not a Slack app. And you can not request specific scopes for it. So for most applications its better to use a Slack App and get a proper access token by installing it.
If you are looking for an example for an installer script, here is a complete script in PHP. It will run on any webserver that supports PHP. Its very basic, but it will work just fine.
I've taken over development of a Google Analytics API dashboard for a content management platform, and upgraded the code to use OAuth2 as the older oauth was disabled recently. The authentication flow and subsequent API calls are all working fine on my localhost for development.
The problem is when trying the code from a different domain. Google wants the redirect_uri to be whitelisted through the developer console, and if it isn't there, it throws Error: redirect_uri_mismatch
As this is a self-hosted (+ open source) package, people will be able of installing on their own servers, there is no way I'll be able of adding all possible redirect_uri values to the app key in the developer console.
After a bunch of Googling and trying to understand the docs, I get the impression there are 2 possible solutions.
Instruct users to go to the Google Developer console, and to create an app key of their own, before also going through the OAuth2 flow within the distributed app to provide the code access to the data in Google Analytics.
Use a redirect_uri value of urn:ietf:wg:oauth:2.0:oob with an Installed App key, instructing people to copy/paste the code back into the self-hosted app after authentication.
Neither of these are really appealing as it adds a bunch of complexity for the user (though option 2 sounds mostly doable). Are there other options, or am I simply overlooking something simple?
You actually don't have any choice in this matter. You must go with nr 1. When you state this is a dashboard and web application it leads me to believe this is some kind of scripting language. This means that the client id and client secret will be displayed to your users / customers. This is against googles terms of service.
Changes to the Google APIs Terms of Service Asking developers to
make reasonable efforts to keep their private keys private and not
embed them in open source projects.
You may not release your client id and client secret to your users they are going to have to create there own. Which nicely solvers your redirect URI problem they have to make there own.
Further reading Can I really not ship open source with Client ID?