`auth.test` in `MultiTeamsAuthorization`
Spencer857 opened this issue · comments
If I understand correctly, various middlewares are applied when a request (e.g., an event) comes in. I'm checking MultiTeamsAuthorization. It's puzzling to me that its implementation includes a call to auth.test. What is the purpose?
As I understand, this call is only really needed to assign enterpriseId. But aren't there other ways to determine it? Also, many apps don't need enterpriseId because they are not enterprise-enabled.
In my app logs, I observed that the Slack API is quite unreliable, and this call often fails. I'm unsure what the end result is, but I suspect those events are dropped.
Can we get rid of this auth.test call?
Hi @the-mark-a1, thanks for asking the question.
The auth.test API call in the middleware has two purposes:
- early detection of invalid token resolution -- tokens stored in your database can be revoked by users; in this case, the following middlware/listeners never work as expected, so this middleware detects such early
- attaching more properties to context -- see the data attached by the API call: https://github.com/slackapi/java-slack-sdk/blob/v1.38.2/bolt/src/main/java/com/slack/api/bolt/middleware/builtin/MultiTeamsAuthorization.java#L237-L266
Since this is an essential design of bolt framework, we don't plan to remove the logic.
In my app logs, I observed that the Slack API is quite unreliable, and this call often fails. I'm unsure what the end result is, but I suspect those events are dropped.
This is not a common situation. The API endpoint is one of the most robust ones. The instability you're experiencing might not be specific to this endpoint. It might be an issue for all the communications with Slack API servers. Generally speaking, the cause for it could be network settings as long as a Slack outage is not happening (edited: sorry for the sentence error).
I hope this clarifies things!
This is not a common situation. The API endpoint is one of the most robust ones. The instability you're experiencing might not be specific to this endpoint. It might be an issue for all the communications with Slack API servers. Generally speaking, the cause for it could be network settings as long as a Slack outage is happening.
I observed that the whole Slack API is unstable, not only auth.test endpoint.
Since this is an essential design of bolt framework, we don't plan to remove the logic.
In this case, I am considering enabling the auth test cache (setAuthTestCacheEnabled(true)). Does it have any negative consequences?
I am considering enabling the auth test cache (setAuthTestCacheEnabled(true)). Does it have any negative consequences?
If your app won't be installed again once it's installed with bot token scopes and your code does error handling due to revoked token within your own middleware and listeners, you can go ahead with the option enabled. Turning it on can bring runtime performance benefits to your app.
If your app won't be installed again
What if it will? This is a public app, so I cannot control user behavior.
The potential side effect of the cache in your scenario could be an accuracy issue with the auth.test API response data within the context object. However, if you don't rely on this data, there's no cause for concern. Does that clarify everything?
But the only thing that is populated there is the enterpriseId, right?
As I mentioned by this link above, botScopes and requestUserScopes can be different if later installations add new scopes after the initial installation. But perhaps you don't need to worry about it, right?
If you don't have anything further to clarify on this, would it be okay to close this issue?
Sure, thanks for all your help.
👋 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.
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.