-
Notifications
You must be signed in to change notification settings - Fork 399
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix #648 Option to disable signature verification #1088
Fix #648 Option to disable signature verification #1088
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1088 +/- ##
==========================================
- Coverage 70.16% 69.55% -0.62%
==========================================
Files 13 13
Lines 1257 1281 +24
Branches 369 377 +8
==========================================
+ Hits 882 891 +9
- Misses 305 319 +14
- Partials 70 71 +1
Continue to review full report at Codecov.
|
@@ -320,12 +328,19 @@ export const respondToUrlVerification: RequestHandler = (req, res, next) => { | |||
next(); | |||
}; | |||
|
|||
export function verifySignatureAndParseRawBody( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wanted to rename the builder method to buildVerificationBodyParserMiddleware
internally but we still need to keep exporting this one for backward compatibility
src/App.ts
Outdated
@@ -59,6 +59,7 @@ export interface AppOptions { | |||
signingSecret?: HTTPReceiverOptions['signingSecret']; | |||
endpoints?: HTTPReceiverOptions['endpoints']; | |||
processBeforeResponse?: HTTPReceiverOptions['processBeforeResponse']; | |||
requestVerification?: HTTPReceiverOptions['requestVerification']; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There may be a better name for this flag. Let me know if you have any suggestions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about signatureVerification
? It feels a bit more specific.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@filmaj That's also an option! But strictly speaking, the validation checks not only the signature but also others like x-slack-request-timestamp: https://api.slack.com/authentication/verifying-requests-from-slack Thus, I'm thinking that "request verification" is slightly more suitable. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I immediately thought of signatureVerification
as well. But requestVerification
also makes sense to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the inputs! OK, let me change the name and see how it looks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
renamed to signatureVerification ✅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Do Bolt or the lower level Slack SDKs have a concept of environments, in the sense of being able to differentiate between a production Slack app, vs. one deployed to a development environment, or even one used in local test suites? The reason I ask is based on the discussion in the original issue, it seems the impetus for this feature is mostly around testing. If testing is the intended use of this feature, perhaps there could be some manner of environment checks in conjunction with this flag to ensure that users don't use this flag for a production application? Just thinking out loud; acceptable answers include "no" 😄
src/App.ts
Outdated
@@ -59,6 +59,7 @@ export interface AppOptions { | |||
signingSecret?: HTTPReceiverOptions['signingSecret']; | |||
endpoints?: HTTPReceiverOptions['endpoints']; | |||
processBeforeResponse?: HTTPReceiverOptions['processBeforeResponse']; | |||
requestVerification?: HTTPReceiverOptions['requestVerification']; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about signatureVerification
? It feels a bit more specific.
@filmaj Thanks for the comment!
This option is indeed useful for testing but the main reason why we decided to add this one in the Java SDK first is, as linked from #648, to support the use cases like having a proxy in front of our server that already checks the Slack signatures: slackapi/java-slack-sdk#689 If the motivation is only for easier testing, we might not add this functionality.
This sounds a good idea but for the above reason, the need to disable the verification in production on the Bolt app side can be valid. We can trust users decisions and have some clear notice in the document like we do for the Java SDK: https://slack.dev/java-slack-sdk/guides/bolt-basics#customize-the-built-in-middleware-list |
We are still discussing the naming |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me!
Do we want to update the documentation to mention this new option?
src/App.ts
Outdated
@@ -59,6 +59,7 @@ export interface AppOptions { | |||
signingSecret?: HTTPReceiverOptions['signingSecret']; | |||
endpoints?: HTTPReceiverOptions['endpoints']; | |||
processBeforeResponse?: HTTPReceiverOptions['processBeforeResponse']; | |||
requestVerification?: HTTPReceiverOptions['requestVerification']; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I immediately thought of signatureVerification
as well. But requestVerification
also makes sense to me.
bdc6257
to
4c2d348
Compare
@seratch thanks for the information and clarification! Much appreciated |
4c2d348
to
ea6abc3
Compare
Resolved conflicts ✅ |
ea6abc3
to
cbb5be5
Compare
Summary
This pull request resolves #648 by introducing a new option
signatureVerification: boolean
inApp
,HTTPReceiver
, andExpressReceiver
. You can verify if the option works with the following example apps:Requirements (place an
x
in each[ ]
)