Skip to main content

Step 10 - Request Filters on the Provider


Move to step 10

git checkout step10

npm install

Learning Objectives

StepTitleConcept CoveredLearning objectivesFurther Reading
step 10Fix the provider to support the 401 caseRequest filters
  • Understand Pact's approach to dealing with complex/dynamic data, such as time-bound authentication tokens

Because our pact file has static data in it, our bearer token is now out of date, so when Pact verification passes it to the Provider we get a 401. There are multiple ways to resolve this - mocking or stubbing out the authentication component is a common one. In our use case, we are going to use a process referred to as Request Filtering, using a RequestFilter.

NOTE: This is an advanced concept and should be used carefully, as it has the potential to invalidate a contract by bypassing its constraints. See for more details on this.

The approach we are going to take to inject the header is as follows:

  1. If we receive any Authorization header, we override the incoming request with a valid (in time) Authorization header, and continue with whatever call was being made
  2. If we don't receive an Authorization header, we do nothing

NOTE: We are not considering the 403 scenario in this example.

In provider/product/product.pact.test.js:

// add this to the Verifier opts
requestFilter: (req, res, next) => {
if (!req.headers["authorization"]) {
req.headers["authorization"] = `Bearer ${ new Date().toISOString() }`;

We can now run the Provider tests

❯ npm run test:pact --prefix provider

Move on to step 11