bolt-js icon indicating copy to clipboard operation
bolt-js copied to clipboard

Using the built-in OAuth, how can I access the rest of the fetched Installation from a listener?

Open aoberoi opened this issue 4 years ago • 14 comments

Description

The built in OAuth is super convenient and great! It fetches the appropriate Installation from my InstallationStore and uses the tokens in that installation to authorize the incoming events. It also puts the relevant User ID and Bot User ID in context so I can access it from middleware and listeners.

But the Installation has so much more in it than just those properties. For example, the installed scopes are stored, an incoming webhook may be stored, etc. If I wanted to access these, I'd currently have to perform installationStore.fetchInstallation() again inside my listener. The framework did that already though, so that's a waste.

This could be solved in probably a few different ways, but I think one of the simplest would just be to add a new (optional) property called installation on AuthorizeResult. The implementation of authorize() that the built-in OAuth library uses would set that property to the whole Installation it got from fetchInstallation(). Any custom authorize() implementations could also set this value. That installation property would then be added to the context, just like botToken, userToken, etc. Then listeners and middleware could use any installation data.

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

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

aoberoi avatar Nov 21 '20 00:11 aoberoi

I like this idea! So developers could access the entire installation object via context.installation..

stevengill avatar Nov 25 '20 20:11 stevengill

Ah, just posted about something similar here: https://stackoverflow.com/questions/67453098/slackbolt-app-how-can-i-get-scopes-associated-with-the-current-request.

Is this the same issue / will this resolve it?

The main use case I care about now is if I want to add permissions over the course of many months to my app (but I don't want to force companies/users to install when I do the update, I can manage that separately), I want a way to basically know which teamIds have which scopes.

Also if there's a workaround in the meantime or a suggested way of doing this, I'd love to hear it! I haven't found anything yet on the public internets :).

maybe.... cc: @seratch will know?

willyxiao avatar May 09 '21 01:05 willyxiao

Hi @willyxiao, thanks for sharing your use case. Yes, if we resolve this issue, the update may be a solution for you. However, we haven't decided how/when we enhance the installation data access yet.

A workaround I can suggest as of today would be defining our own authorize function that utilizes installation store. With this way, you can add any additional fields to the context object. Refer to https://slack.dev/bolt-js/concepts#authorization for learning how to implement it.

For the authorize with custom fields, I need to mention a limitation with TypeScript. If you write your app in TS, the AuthorizeResult interface is not yet customizable as a type.

seratch avatar May 09 '21 23:05 seratch

Thank you SO much! Super helpful. @seratch one question - the current default authorize function looks like it's making a call to slack (via client.auth.test on line 890 in App.ts).

  1. Is that what's ultimately calling fetchInstallation as I see in my logs, or am I misunderstanding? If I am, where is fetchInstallation called now? I just want to understand what default behavior, so that I can emulate the parts that I need when I override it with a new authorize function.

  2. Kind of on a separate note, it kind of seems like I can pass tokenVerificationEnabled = false and that should actually improve my response times / decrease latency if I keep the default authorize function. Especially if ack() is called after 3 seconds every once in a while in our case, passing that option in tokenVerificationEnabled should actually have an effect of making ack succeed more often, right?

willyxiao avatar May 10 '21 00:05 willyxiao

@willyxiao

the current default authorize function looks like it's making a call to slack (via client.auth.test on line 890 in App.ts).

This is only for the case where you pass a token in App constructor. In this case, your app works only for a single workspace , so that it uses singleAuthorization for its authorize. This is not the case you mentioned here. https://github.com/slackapi/bolt-js/blob/9867e382e94646b518d05c3e71d7947aad699692/src/App.ts#L359-L367

Is that what's ultimately calling fetchInstallation as I see in my logs, or am I misunderstanding? If I am, where is fetchInstallation called now?

If your app enables OAuth and its installation store functions, Bolt uses the HTTPReceiver's default authorize function for OAuth: https://github.com/slackapi/bolt-js/blob/9867e382e94646b518d05c3e71d7947aad699692/src/App.ts#L375 This authorize function calls fetchInstallation internally.

tokenVerificationEnabled

tokenVerificationEnabled is a flag option for turning the eager verification of the given token value in App constructor on/off. Therefore, this is not an option for you. This option works only with the bult-in singleAuthorization.

Although it's not active recently, this is an issue for bolt-js's enhancement discussion. If you have followup questions or related ones, would you mind creating a new issue for your question or asking them in the Slack Platform Community workspace? In the community workspace, #lang-javascript #tools-bolt would be good places to have this type of Q&A. I would appreciate it if you could understand this!

seratch avatar May 10 '21 01:05 seratch

What is supposed to be returned exactly from the fetchInstallation call if using a publically installed app with Oauth? I am returning the authorized bot user token stored in my database as a string for the user invoking the app, but I get the error below:

[WARN] bolt-app Authorization of incoming event did not succeed. No listeners will be called. [ERROR] bolt-app Error: Cannot read property 'token' of undefined

anthonygualandri avatar Jan 11 '22 23:01 anthonygualandri

@anthonygualandri Please refer to the document: https://slack.dev/bolt-js/concepts#authorization

To know the full list of available properties, you can check the AuthroizeResult interface here: https://github.com/slackapi/bolt-js/blob/%40slack/bolt%403.8.1/src/App.ts#L113-L139

seratch avatar Jan 11 '22 23:01 seratch

Thanks @seratch and I'm so sorry, but I'm confused. The spot in the docs you sent me to says "If you’re using the built-in OAuth support authorization is handled by default, so you do not need to pass in an authorize option." Can it be something else here instead that you can point me to?

anthonygualandri avatar Jan 11 '22 23:01 anthonygualandri

@anthonygualandri Oh, I'm sorry. Somehow, I assumed that you've asked about authorize function. Please check this interface to learn the expected data structure as a returned value form fetchInstallation method: https://github.com/slackapi/node-slack-sdk/blob/%40slack/oauth%402.3.0/packages/oauth/src/index.ts#L636-L700

seratch avatar Jan 12 '22 00:01 seratch

Thanks @seratch, this is exactly what I needed and helped me get the right return values into the right data structure to get the app installing / loading properly. Will look to the code in the package in the future for anything that isn't detailed out in the Bolt concepts guide.

anthonygualandri avatar Jan 12 '22 21:01 anthonygualandri

is there an estimated release date for 4.x?

LeoDOD avatar May 24 '22 18:05 LeoDOD

Hey there, I got here because I'd like to access the team name from the installation object without getting it again from the DB.

The "problem" as you said is that the authorize function get the whole installation, but it only returns the fields needed by the AuthroizeResult interface, so I basically need to override that method. The fact is that all the properties and utility methods are private, so I ended up basically rewriting the whole InstallProvider class because I can't access those methods from the subclass I created to override the authorize method.

Have you came up with a better solution that doesn't involve an useless database query?

acerbisgianluca avatar Apr 11 '24 19:04 acerbisgianluca