CODEWITHSUNDEEP
botframeworkslack-api
Martín La Rosa
Martín La Rosa

Reputation: 810

Bot Framework dotnet Slack adapter fails to verify Slack request when changing the Events Request Url

I have a Slack bot that is working fine and interacting with users. I'm using Bot Framework composer and the Slack Adapter. In the Slack API portal I'm trying to change the Events Request Url the app uses to send Slack Events to my bot. When I do that, slack sends a challenge request to my bot. The bot first tries to verify that the request is really coming from Slack following: https://api.slack.com/authentication/verifying-requests-from-slack#a_recipe_for_security

The problem is that this is failing and I can't understand why. I see that Slack is sending all the right content, and that the ClientSigningSecret is being read, otherwise the other calls to the bot wouldn't work.

I know it's a bit far fetched to ask this since it seems to be a problem on my side. But since the bot is validating the requests just fine when users talk to the bot, and the code is from the Slack Adapter which is open source and there's nothing else I can thing of..... maybe someone struggled with the same problem.

Upvotes: 0

Views: 138

Answers (1)

Martín La Rosa
Martín La Rosa

Reputation: 810

I created a support ticket to Slack and they came back pretty quickly.

Pre publish state

Before publishing a Slack app the only configs that exist are the ones you see in the App configuration page. Those are what you use to test your app, this includes the secrets to authenticate the incoming messages from Slack into your backend.

After you publish your Slack App for the first time

Once your app is published, the production version that your users use will see the original settings, including the secrets and these are the ones your backend will get. The settings you see in the configuration page are like development mode and they won't be persisted into the published app until you request Slack to approve your changes. That's sounds great and is what one would expect, but what you don't see and have no way of imagining is happening is that there are some development time secrets that are different from the ones you see on the settings screen.

When you change the endpoint url to be sent to your backend so that it can return the challenge and Slack would accept the new url, the message payload goes with this development secret and not the one you configured your backend with. Thus your backend will reject the call since it thinks it's not coming from Slack.

Proposed solution from Slack

Don't validate the signature of the incoming request for this type of call in an already published app. I don't like it but there was no other workaround unless Slack changes this. So what I did was:

  1. Remove that check only for this request from the backend and publish to production.
  2. Make the url change in Slack.
  3. Revert the change from the backend.

:(

Upvotes: 0

Related Questions