Skip to content
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

Add support for validating MS Teams outgoing webhooks #512

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

emilhf
Copy link

@emilhf emilhf commented Feb 21, 2021

Hi. Great project.

MS Teams supports outgoing webhooks for implementing lightweight chat-ops. However, the signature digest scheme is somewhat wonky and benefits greatly from a dedicated signature type, similar to the one already offered for scalr. Today, this needs to be done by the scripts themselves, which is less ergonomic.

If accepted, I'll look into writing some simple examples/docs as well.

@moorereason
Copy link
Collaborator

I would rather not add more snowflake options for individual services. Any ideas on a more generic solution are welcome.

The Scalr issue could be solved by a duration rule. This MS Teams issue appears to need some string concat/prefix/suffix actions before the compare. In pseudocode: eq(concat("HMAC ", sha256(payload, "secret")), header("Authorization")). I don't have any good ideas at this point on of how to extend our current config rules to accommodate that.

@emilhf
Copy link
Author

emilhf commented Feb 22, 2021

Point taken. Took a quick peek at the previous discussion on context providers, which looks promising, although I'm not sure of the current state of this effort. Another option, at the cost of complexity, might be to add some kind of transform option, either for validation or for incoming headers in general. It might work with a simple stack-oriented approach with generic unary/binary functions, which would be easy to express using a list in JSON/YAML. I'm not entirely sure of the ergonomics or general usefulness of this though. And at this level of complexity, it would likely be better to prioritize other possible features instead, like some kind of schema validation for building more robust and discoverable webhooks.

@adnanh
Copy link
Owner

adnanh commented Feb 25, 2021

I started playing around with creating a new trigger rule that evaluates arbitrary expression using cel-go. It would greatly increase the rule flexibility and we could probably work towards phasing out some of the standard rules in favor of expressions?

But yeah, it would be nice to standardize and create a pipeline request goes through, and expose hooks where the user scripts could transform payload, provide dynamic props to webhook (like the context-provider) and even provide the response body, headers, status code, etc...

Maybe it would worth starting a solution design/plan discussion on this topic?

@moorereason
Copy link
Collaborator

Yes, open an issue to discuss expression evaluation because I've been tinkering with the exact same idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants