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
Given a pact with request header authorization: some_token When verifying pact via Pact FFI function And using pactffi_verifier_add_custom_header to replace authorization value with other_token Then pact verifier makes request with authorization: some_token
What should happen:
Given a pact with request header authorization: some_token When verifying pact via Pact FFI function And using pactffi_verifier_add_custom_header to replace authorization value with other_token Then pact verifier makes request with authorization: other_token
An alleged fix was mentioned in this discussion: #275 (comment) (cc @rholshausen )
It was difficult to track down the version in which the fix was included, but since:
Additionally, replacing headers added by this function itself works:
pactffi_verifier_add_custom_header(verifierhandle, "foo", "bar");
pactffi_verifier_add_custom_header(verifierhandle, "foo", "baz");
// The outcome - `foo: baz` is included in headers
Let me know if there is any extra context I could provide from my side to track down the problem quicker.
The text was updated successfully, but these errors were encountered:
I actually found a solid workaround for the problem I was trying to solve with this.
The issue I had was that I wanted to use a real authentication token when verifying the provider. Consumer obviously used a fake token, which was not an issue on its side, but I wanted to replace with with a real token in provider so that the auth flow would be covered as well.
That's why not being able to override the header was a problem. I would have had to exclude auth header from consumer side.
How I solved the problem with existing pact features:Matchers.fromProviderState in combination with state change callback
Uses Bearer my-fake-token when running consumer tests
Uses authToken variable from Provider tests state change callback (see below)
Checks that provider matches Bearer <JWT> regex
On the Provider side (I am using elixir, but it's quite universal)
defstate_change(conn,params)docaseparamsdo%{"state"=>"some state"}-># Using a helper function to generate real auth tokenauthToken=generateAuthToken()conn|>put_status(:ok)|>json(%{authToken: authToken})_->conn|>put_status(:ok)endend
What this does:
the state_change function is what the State Change URL endpoint given to pact verifier would call with POST
The response includes values to be replaced
${authToken} will be replaced with the generated real auth token
Maybe this might help someone trying to find a good solution for authentication in pact verifier as well.
What happens:
Given a pact with request header
authorization: some_token
When verifying pact via Pact FFI function
And using
pactffi_verifier_add_custom_header
to replaceauthorization
value withother_token
Then pact verifier makes request with
authorization: some_token
What should happen:
Given a pact with request header
authorization: some_token
When verifying pact via Pact FFI function
And using
pactffi_verifier_add_custom_header
to replaceauthorization
value withother_token
Then pact verifier makes request with
authorization: other_token
An alleged fix was mentioned in this discussion: #275 (comment) (cc @rholshausen )
It was difficult to track down the version in which the fix was included, but since:
... I tried 0.4.17, but the headers can still not be overwritten (even tried the current latest version 0.4.20 for good measure, but no luck).
For context, here is where we are attempting to use this feature: https://github.com/salemove/pact_erlang/blob/9945d0bd1ea882812e62db61171bd8671b60b2db/c_src/pactffi_nif.c#L707.
The headers get nicely added when I do something like:
Additionally, replacing headers added by this function itself works:
Let me know if there is any extra context I could provide from my side to track down the problem quicker.
The text was updated successfully, but these errors were encountered: