Additional follow-up question, related to webhooks, namely authenticating webhook request. We are using Jenkins CI, and when we define a webhook for pact broker to trigger a build, we also need to provide Jenkins credentials along with the request. What is the best way for doing that? 1. If we make the credentials available to the pact-broker service via env variables, is there a way to use those in the request (similarly to pact variables)? 2. Should we perhaps approach this differently and create/update webhook on every consumer build via create-or-update-webhook script in Consumer CI, (where we have Jenkins credentials available), and provide the tokens alongside it? a. Although it already seems silly as I put it into words, as the token could be later exposed when fetching the webhooks 🤷_._

not in the open source broker i’m afraid you’ll need to store the token in the webhook

I wonder if making modifications to pact-broker to support using env variables in webhook requests would be difficult 🤔

i stop get reqs to /webhooks to avoid them being shown to casual users. pactflow supports encrypted secrets and variable substitution

i stop get reqs to /webhooks to avoid them being shown to casual users.

That's an idea indeed.

i did some work in the past but it never saw the light of day https://github.com/pact-foundation/pact_broker/pull/262 along with Beth to introduce secrets, although she approached it in a different way in PactFlow.

Looking at the work that @Beth (pactflow.io/Pact Broker/pact-ruby) did with secrets. So basically this would be the solution to this issue, right? We could store our CI credentials in a secret and somehow we could use the secret ID in our webhook and pact-broker would substitute it when making the request?

That's the idea, although the secrets capability is only available in Pactflow. I forgot about that PR Yousaf!

although the secrets capability is only available in Pactflow

currently or is it meant to be like that for the forseeable future as a selling point for pactflow (not judging)?

Yeah it was added to Pactflow as part of the initial SaaS offering. There's no plans to add it to the OSS broker at this stage

The work was implemented in a different way in PactFlow and supported by the commercial project. Due to time/support constraints, the work on secrets was never completed in the OSS broker. Controlling access to your broker in your own infra isn’t something maintainers can control, and therefore it is anticipated that appropriate steps are taken to control access to your broker. (various mechanisms for doing this) We probably wouldn’t stop a PR from going ahead to introduce this functionality coming into the pact broker, but would expect its implementation to be of sufficient quality, have appropriate documentation and be supported for some time by the author, in case of issues. We would also need to check for compatibility with the pactflow broker, but that is something we can do on the PactFlow side during review Beth’s previous branch would be a good starting point, but there are some changes to the pact-broker codebase now, that would require some rework of that existing branch

Thank you both! 🙇