Where to map slack resources to my own org's resources when oauth completes?

[TroutZen]

Description

Hi there. My team is building a new slack app with slack bolt. I was looking for guidance on a particular question. We are currently building out the oauth flow which redirects to our own application after the user accepts the application scopes so that we can authenticate the user in our platform before completing oauth with slack. After authenticating the user in our platform we complete the oauth flow which eventually triggers the installationStore's storeInstallation method per example below:

installationStore: {
    storeInstallation: async (installation) => {
      if (installation.isEnterpriseInstall) {
        // support for org wide app installation
        return await database.set(installation.enterprise.id, installation);
      } else {
        // single team app installation
        return await database.set(installation.team.id, installation);
      }
      throw new Error('Failed saving installation data to installationStore');
    },
    ...
  },

The problem that I am facing is that when I store the installation I also want to be able to link up the relationships between the slack user and the user I know in my own application (i.e. slack user id <> my orgs user id). However, there is nothing that I can pass into this callback from the request that would allow me to do that. What I would like to be able to do is read from the request so I can pull out org specific information that I can use when storing tokens. For example

storeInstallation: async (request, installation)

Would appreciate feedback from this request or perhaps a suggestion on how to best handle this problem.

Thanks!

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

• bug
• enhancement (feature request)
• question
• documentation related
• example code 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.

[mwbrooks]

Hi @TroutZen,

Thanks for reaching out and clearly explaining your use-case!

At the moment, @slack/bolt-js and @slack/oauth don't provide a built-in way for you accomplish your goal. However, your issue has sparked a nice discussion between some of the Bolt framework maintainers. I think we'd all like to see more flexibility, so that you easily add some before/after logic to an installation.

For now, I've labelled this as a question but I think we can turn it into a discussion when we have a loose proposal. Currently, the discussion is considering a beforeInstallation and afterInstallation callback that provides access to {req, resp, installOptions}.

If you have any initial thoughts, feel free to drop them here!

[TroutZen]

Thanks @mwbrooks, I think passing in req, resp, installOptions would allow us to accomplish our goals in this scenario. I should note that we are using custom koa endpoints that delegate calls into installer.handleCallback because of the need to perform some custom logic before bolt's internals take over. In this scenario it would nice if we could pass in custom args that eventually get passed into storeInstallation, but that feels like a much more specific / nuanced use case.

The only additional thing I might add is that we considered adding some of this logic to installer.handleCallback's success callback, but also ran into challenges there because the success callback was not async (which we would have wanted in order to perform async DB updates) and because the success callback did not have out of the box support for having access to req or res.

[seratch]

Hi @TroutZen, thanks for your prompt reply here!

In this scenario it would nice if we could pass in custom args that eventually get passed into storeInstallation, but that feels like a much more specific / nuanced use case.

If I understand your use case correctly, enhancing the storeInstallation method does not work for you in the best way. Slack app installations are done when your app performs an oauth.v2.access API call with given code query parameter. The storeInstallation method is supposed to be called after an installation completes. Even if you don't store the tokens and its metadata, the installations are already successfully completed.

If you are thinking to revoke the installation (by calling auth.revoke API method) in storeInstallation method, it may work in some situations. That being said, obviously it's not a straight-forward solution.

This is why our team discussed the necessity to introduce a new method like beforeInstallation (although we haven't decided to work on it in the short term).

ran into challenges there because the success callback was not async

Thanks for the input. We've been aware of this but changing this is a breaking change. In future major version upgrades, we may improve it.

[github-actions]

👋 It looks like this issue has been open for 30 days with no activity. We'll mark this as stale for now, and wait 10 days for an update or for further comment before closing this issue out. If you think this issue needs to be prioritized, please comment to get the thread going again! Maintainers also review issues marked as stale on a regular basis and comment or adjust status if the issue needs to be reprioritized.

[RomainCscn]

Hello @TroutZen, did you find a solution to map your installation with you own org data?
I'm facing the same problem, I can't find a way to link a slack installation to our data.

@seratch do you have something to suggest for this? Or should I use @slack/oauth as I could put some metadata and retrieve it after?

installer.generateInstallUrl({
  scopes: ['channels:read'],
  metadata: JSON.stringify({org_id:'1234'})
})

[seratch]

@RomainCscn Currently, the @slack/oauth package does not provide any easy way to achieve your goal. We are planning to add new callbacks that Michael mentioned above #1211 (comment)

Due to other priorities, we didn't have the bandwidth to work on it but recently I started using my time for the OAuth package improvements including this task.

It won't take long but we cannot tell when we can ship the new features yet. If you need an immediate solution, one workaround that I have to suggest is to go with your own implementation reusing some parts of the OAuth package such as the authorize URL generation. With this way, you can set any cookies to your end-user's browser session. That would be much easier way. I hope this helps.

[seratch]

#1391 enables a new way to handle this use case. Since the next version, developers can utilize installPathOptions.beforeRedirection and callbackOptions.beforeInstallation to do additional validation and so on.

Checking "Persisting data during the OAuth flow" section in https://slack.dev/node-slack-sdk/oauth would be helpful to understand how to use those callback functions.

Let me close this issue as the one that will be resolved in v3.11 release milestone.

[RomainCscn]

#1391 enables a new way to handle this use case. Since the next version, developers can utilize installPathOptions.beforeRedirection and callbackOptions.beforeInstallation to do additional validation and so on.

Checking "Persisting data during the OAuth flow" section in https://slack.dev/node-slack-sdk/oauth would be helpful to understand how to use those callback functions.

Let me close this issue as the one that will be resolved in v3.11 release milestone.

Thanks for your reply. Do you know when the v3.11 will be released?

[seratch]

@RomainCscn If everything goes well, we can ship it within a few business days! I've done with all the remaining pull requests for the release and am waiting for reviews by other maintainers. At least, we can release beta or RC version in the time frame.