Home > Mobile >  Add Authorization header to provider request
Add Authorization header to provider request

Time:07-06

As part of my pact provider verification I need to add an Authorization header to the request sent to the provider.

There is the gradle variant:

requestFilter = { req ->
                // Add an authorization header to each request
                req.addHeader('Authorization', 'OAUTH eyJhbGciOiJSUzI1NiIsImN0eSI6ImFw...')
            }

But I want to use JUnit since it is simpler on the syntax side. And doesn't require new EPs for state management. But I cant find the equivalent of adding this to the request.

My Pact is:

RequestResponsePact pact = ConsumerPactBuilder
                    .consumer("MyConsumer")
                    .hasPactWith("my-provider")
                    .given("There are entities in qn-deployment")
                    .uponReceiving("A parameterized entities query")
                    .path("/api/2.0/entities")
                    .headers("Authorization", "Bearer xxxxxxxxxx")
                    .query("types=network&ids=1001&ids=1002&ids=1003&entities_list_format=details&contained_in_list_format=details&contained_in_list_group_by_type=false&contained_in_list_recursive=false&contained_in_list_deep=true&contains_list_format=none&contains_list_group_by_type=false&contains_list_recursive=false&contains_list_deep=false")
                    .method("GET")
                    .willRespondWith()
                    .headers(headers)
                    .status(200)
                    .body(body)
                    .toPact();

But the header isn't sent with the request and doesn't appear in the pact when examining in the pact broker. My question is how to make the consumer side send the header in the request. When using the .header chained method after the .willRespondWIth() then the contract expects the Authorization header to be present in the response. Putting it before changes nothing in the contract. It is ignored.

CodePudding user response:

The header is a part of the contract, I'd propose to propagate it from the consumer side as it does affect the response. A client might want to send you an auth header that causes 403 - it's a contract as well.

Best practices are:

  • Keep the header constant from run-to-run
    • all the values in JWT must be constants, e.g. you can set a constant date inside
  • But JWT token expiry time to something long (aka 2122 till year) to prevent expiration failure on the provider side

The consumer pact will look like:

...
                    .uponReceiving("A parameterized entities query")
                    .path("/api/2.0/entities")
                    .matchHeader("Authorization", "Bearer .*", "Bearer xxxxxxxxxx")
...
                    .method("GET")
                    .willRespondWith()
                    .headers(headers)
                    .status(200)
                    .body(body)
                    .toPact();
  • .matchHeader("Authorization", "Bearer .*", "Bearer xxxxxxxxxx")
    • Bearer xxx goes as an example and the exact value on provider side to call it
    • Bearer .* will be used on the consumer side to verify the request header when you call pact stub server
  • Related