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

Modify BitBucketInterceptor to BitbucketInterceptor #596

Merged
merged 1 commit into from
Jun 19, 2020

Conversation

savitaashture
Copy link
Contributor

@savitaashture savitaashture commented Jun 4, 2020

Changes

  1. Updated README to mention specifically that the interceptor supports for bitbucket server not for bitbucket cloud.
  2. Modified name for the Bitbucket interceptors in order to match with atlassian doc

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you
review them:

See the contribution guide for more details.

Fixes: #362

@tekton-robot tekton-robot added the size/M Denotes a PR that changes 30-99 lines, ignoring generated files. label Jun 4, 2020
@savitaashture savitaashture changed the title Modify name for BitbucketInterceptor Modify BitBucketInterceptor to BitbucketInterceptor Jun 4, 2020
@@ -421,7 +421,7 @@ spec:
### Bitbucket Interceptors

Bitbucket Interceptors contain logic to validate and filter webhooks that come from
Bitbucket server or cloud. Supported features include validating webhooks actually came from Bitbucket as well as
Bitbucket server and not the Bitbucket cloud. Supported features include validating webhooks actually come from Bitbucket server as well as
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about something like...

The Bitbucket interceptor provides support for hooks originating in Bitbucket server, providing server hook signature validation and event-filtering.

Bitbucket cloud is not currently supported by this interceptor, but it has no secret validation, so you could match on the incoming requests using the CEL interceptor.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: what would it take to support bitbucket cloud?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bitbucket cloud interceptor doesn't support secret validation, but it could match on the event types.

Couple of options, maybe an extra parameter for the interceptor to indicate cloud or server?

Or try one and then the other, but the JSON bodies are actually quite different between them.

(This is "solved" by my hook standardisation proposal 🙂)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, lemme clarify, Bitbucket cloud doesn't send secrets to validate.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://confluence.atlassian.com/bitbucket/manage-webhooks-735643732.html

Secure webhooks

Webhooks work Bitbucket sending a POST to the customer service at a particular URL.
It's important that you protect your service from potential attacks. As a workaround, you
could whitelist the Bitbucket IPs to restrict who can access your webhook resource.

So, maybe instead of secrets, for the "cloud" version, you add the list of IPs?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh ok, did not realize cloud did not support shared secret validation. IP whitelisting might get a bit complex for scenarios where there are other entities like reverse proxies or knative eventing processing the request before the EventListener. Maybe just the types are fine for now until the standardized hook type?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about something like...

The Bitbucket interceptor provides support for hooks originating in Bitbucket server, providing server hook signature validation and event-filtering.
Bitbucket cloud is not currently supported by this interceptor, but it has no secret validation, so you could match on the incoming requests using the CEL interceptor.

@bigkevmcd is that okay if we include work hook right now in the doc because it may lead to confusion on what can be hook so just wanted to clarify before updating PR

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh ok, did not realize cloud did not support shared secret validation. IP whitelisting might get a bit complex for scenarios where there are other entities like reverse proxies or knative eventing processing the request before the EventListener. Maybe just the types are fine for now until the standardized hook type?

@dibyom Maybe just the types are fine for now until the standardized hook type? Could you please help me to understand what will be type here

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was just referring to the eventTypes field. Going through this again -- I think adding @bigkevmcd 's suggested change seems like a good way to proceed here!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dibyom Updated README as per the @bigkevmcd suggestion

Copy link
Member

@dibyom dibyom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bigkevmcd anything else remaining for this PR?

@tekton-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dibyom

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@tekton-robot tekton-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jun 16, 2020
@dibyom
Copy link
Member

dibyom commented Jun 19, 2020

/lgtm

@tekton-robot tekton-robot added the lgtm Indicates that a PR is ready to be merged. label Jun 19, 2020
@tekton-robot tekton-robot merged commit 03e6e32 into tektoncd:master Jun 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

How to expose the EventListener to Bitbucket webhook
4 participants