You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: README.md
+40
Original file line number
Diff line number
Diff line change
@@ -921,3 +921,43 @@ FAILURE: Build failed with an exception.
921
921
```
922
922
923
923
Oh, dear. _More_ tests are failing. Can you understand why?
924
+
925
+
## Step 10 - Request Filters on the Provider
926
+
927
+
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`.
928
+
929
+
_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://docs.pact.io/implementation_guides/jvm/provider/junit5/#modifying-the-requests-before-they-are-sent for more details on this.
930
+
931
+
The approach we are going to take to inject the header is as follows:
932
+
933
+
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
934
+
1. If we don't receive an Authorization header, we do nothing
935
+
936
+
_NOTE_: We are not considering the `403` scenario in this example.
937
+
938
+
In `provider/src/test/java/au/com/dius/pactworkshop/provider/ProductPactProviderTest.java`:
0 commit comments