Step 10 - Request Filters on the Provider

info

Move to step 10

git checkout step10

Javascript

npm install

Learning Objectives

Step	Title	Concept Covered	Learning objectives	Further Reading
step 10	Fix the provider to support the `401` case	Request 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 https://github.com/DiUS/pact-jvm/blob/master/provider/junit/README.md#modifying-the-requests-before-they-are-sent for more details on this.

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

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
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:

Javascript

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

We can now run the Provider tests

❯ npm run test:pact --prefix provider

Move on to step 11

Learning Objectives​

Learning Objectives