👋 I wanted to check here before exploring other options (apologies if it’s been mentioned/answered elsewhere - I searched this channel and the issues on the broker but couldn’t find anything) We’ve got the OSS broker setup and I’m going through the CI/CD setup/pact nirvana steps, and had a couple of questions around secrets/webhook auth… as per the point at the beginning of the steps:

Note that if you are using your own instance of the open source Pact Broker, it does not support secrets, and it does not have a user interface for managing webhooks. You’ll need to use the API or HAL Browser to create the webhook, and your CI token will have to be stored in plain text in the webhook. See the Webhooks API reference docs here

In our case (where our CI provider doesn’t have any granularity on the capabilities for an api token, and creating a machine user comes with some other downsides) I wanted to know if this is something that the OSS broker does not intent to support? Is this something we contribution? Another small question I had was: In the webhook template examples, for github there’s a template variable

user.GithubToken

but in the docs on what’s available for variable substitution there’s nothing there 😕 - is it a pactflow-only value? or from something else?

Ahh my apologies, I inadvertently brought in the

user.GithubToken

in during this change when updating. It is PactFlow only that, so will update to reflect. https://github.com/pact-foundation/docs.pact.io/commit/e60945f518b353b6c72e796fa6c18d9ea19880ec

I wanted to know if this is something that the OSS broker does not intent to support?

Not sure on this answer. I did look to implement token redaction, in this PR where Beth started working on some secrets func in the Pact Broker https://github.com/pact-foundation/pact_broker/pull/262#issuecomment-501914838 It was around that time that PactFlow was launched and no free time was available for Pact Broker playtime, so it never progressed futher. Might be a decent starting point to have a look.

👍 ah nice - I saw that issue and for some reason didn’t open it up facepalm Reading through it however I see it mentions that the

Authorization

header is auto-redacted? I hadn’t seen that mentioned anywhere in the docs and hadn’t thought to just try it out 🙃 That should cover my use case to be honest - we’re on circle and the token for webhooks is in that auth header, I’m not that fussed about a user’s api token in the db/plaintext if it’s not accessible from the api 👍

> I wanted to know if this is something that the OSS broker does not intent to support?

Not sure on this answer.

My question was more a “is this not in the oss pact broker because it’s a differentiator between it and pactflow” - I’ve not seen that sort of vibe anywhere else though to be fair 🙂

yeah they are already redacted in the body, the docs page seems to be lost in the midst, but the reference is here https://github.com/pact-foundation/pact_broker/blob/9529c6790eb74f70aa61df2cd2c067ffdfd3769c/lib/pact_broker/doc/views/webhooks.markdown?plain=1#L80 Depending on your setup, for example if you are using nginx, you can block access to certain API routes completely https://blog.you54f.com/2019/03/19/securing-the-pact-broker-with-nginx-letsencrypt/ to say get requests on the webhooks endpoint, and leave it open for posts only.

• Whilst implementing webhooks, I noted that URL based tokens are visible to users both rw/ro, to the pact-broker, so we are blocking access to the

/webhooks

url. This will also block

/webhooks/**

error_page 418 = @blockAccess;
 
location /webhooks {
return 418;
}
location @blockAccess {
deny all;
}

I suppose it depends on your setup but you should be good to go as is, it seem s:)

Ah excellent - yeh our token is in

Circle-Token

so I think we should be good 🙂