Unfurl links when the app is installed in the workspace
Closed this issue · 2 comments
I have an app that has OAuth enabled with bot and user scopes. I want to unfurl my service-related links. The app is configured to unfurl my domains and is subscribed for link_shared
events. I'm using the default InstallProvider
from @slack/oauth
package.
When the user has the app installed, everything works as a charm. However, when the app is installed in the workspace, but the link is shared by another user who doesn't have the app installed yet, it is impossible to unfurl the link as fetchInstallation
cannot get user credentials, and the link_shared
handler is not called at all even though it should be enough to use bot
token for actions like this.
The service that has @slack/bolt
up and running receives the following request when the link is shared by someone without App installed yet:
{
token: 'XxX',
team_id: 'TEAM_ID',
api_app_id: 'XXXX',
event: {
type: 'link_shared',
user: 'USER_ID',
channel: 'COMPOSER',
message_ts: 'XXX',
links: [ {} ],
source: 'composer',
unfurl_id: 'XXXX,
is_bot_user_member: true,
event_ts: '1707211829.806331'
},
type: 'event_callback',
event_id: 'XXXX',
event_time: 1707211829,
authorizations: [
{
enterprise_id: null,
team_id: 'TEAM_ID',
user_id: 'BOT_USER_ID',
is_bot: true,
is_enterprise_install: false
}
],
is_ext_shared_channel: false,
event_context: 'XXXX'
}
and fetchInstallation
is called with
{
installQuery: {
userId: 'USER_ID',
isEnterpriseInstall: false,
teamId: 'TEAM_ID',
enterpriseId: undefined,
conversationId: 'COMPOSER'
}
}
and of course, fetchInstallation
cannot return the token even though the authorizations
array contains is_bot: true
and bot user id. I assume that buildSource
(from App.ts
) does not respect is_bot: true
and requires the user to have the app installed even for actions that require only bot permissions.
Are there any ways to react to link_shared
events and unfurl all links shared in the workspace when the App is installed for at least one user?
The Slack SDK version
"slack/bolt": "^3.17.0",
"slack/oauth": "^2.6.1",
"slack/web-api": "^6.11.0",
Node.js runtime version
v20.9.0
Hello,
The default installation store is very simplistic and should not be used in production. It only works with bot scopes; once user scopes are involved, the default installation store is too simplistic to handle the various use cases that may come up (as you've experienced).
Our recommendation is to customize the saving and retrieving of credentials during the OAuth flow. Specifically, we call the process of retrieving (or "fetching") credentials authorization. Have a read through the authorization documentation. It may also be helpful to see how the store
/fetch
/deleteInstallation
handlers are implemented in the Bolt OAuth example. The code for default file installation store is here, in case reviewing this (short) source code is helpful to understand what is happening under the hood.
In your situation, overriding these *Installation
methods should be thought out from the perspective of multiple installation types and personas. Specifically, it sounds like some part of the default File Installation store is not executing during authorization for users who have not granted user scope permissions. This is a concern that your custom *Installation
methods should take into consideration.
I hope that helps.
Hello @filmaj, yes, it did help! Investigating the file installation store helped a lot. Thanks