Best way to access app-specific data in installationStore methods?

[jkillian]

I've been reading the docs on custom data in the oauth flow and also found slackapi/bolt-js#1211 but had a couple remaining questions on associating the oauth data from Slack with application-specific data.

What is the proper way to access app-specific data when using a custom installationStore as documented in "Storing installations in a database"? For example, in the storeInstallation callback, such information might be necessary in order to be able to write a slack token to the correct row in associated with some user in a DB.

Also a bit confused on if metadata is still supposed to be used ever or not - it wasn't clear to me if the new beforeInstallation and beforeRedirection were suppose to supplant any use cases for metadata or not.

Apologies if I'm missing something obvious! Just wanted to be extra careful given that small mistakes in auth flows can have big consequences.

Packages:

Select all that apply:

• @slack/web-api
• @slack/rtm-api
• @slack/webhooks
• @slack/oauth
• @slack/socket-mode
• I don't know

Reproducible in:

The Slack SDK version

"@slack/oauth": "2.5.1"

[seratch]

Hi @jkillian, thanks for asking the great question!

Also a bit confused on if metadata is still supposed to be used ever or not - it wasn't clear to me if the new beforeInstallation and beforeRedirection were suppose to supplant any use cases for metadata or not.

We didn't remove the metadata approach to avoid bringing any breaking changes to existing apps. Also, metadata can be useable for the purpose. However, I would suggest using the pair of installPathOptions.beforeRedirection and callbackOptions.beforeInstallation instead going forward. The benefits of the new way would be:

• More flexible - you can reuse not only the cookies that your Slack app OAuth flow set but also the ones set by other OAuth interactions and/or your service's authentication session
• Separate the logic from the metadata generation - you can separate and simplify the logic to write and read your app specific user state - the newly added callbacks are simple HTTP request/response handlers

What is the proper way to access app-specific data when using a custom installationStore as documented in "Storing installations in a database"? For example, in the storeInstallation callback, such information might be necessary in order to be able to write a slack token to the correct row in associated with some user in a DB.

As I explained above, we suggest the new way (beforeRedirection and beforeInstallation). That being said, if you have existing apps that rely on metadata, you don't need to migrate those to the new way. We will continue supporting both approaches.

Do these make sense to you? I hope this was helpful to you!

[jkillian]

Thank you for the detailed response!

As I explained above, we suggest the new way (beforeRedirection and beforeInstallation).

The issue I'm running in to is that in storeInstallation I want to write the returned credentials to a specific row in our DB corresponding to the app-specific user who started the flow. However, because storeInstallation is only passed an installation parameter, and nothing else, unless I use metadata, there's no way to know what user started the whole request, and so there's no way to know what row in the DB to update.

Does that make sense? I don't see how beforeInstallation could help in this scenario unless I wrote all the data to the DB in that step and then just made storeInstallation a no-op. Is that what you're recommending for this situation?

[seratch]

@jkillian
For your use case, you can use afterInstallation callback to attach additional information to the installation data.

• https://slack.dev/node-slack-sdk/reference/oauth#callbackoptions
• https://github.com/slackapi/node-slack-sdk/blob/%40slack/oauth%402.5.1/packages/oauth/src/install-provider.ts#L655-L668

If you develop your app in TypeScript, the type safety for the additional properties is room for improvement on the SDK side.

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

[github-actions]

As this issue has been inactive for more than one month, we will be closing it. Thank you to all the participants! If you would like to raise a related issue, please create a new issue which includes your specific details and references this issue number.