Hello Pact team, I am getting error for hardcoded ...
# pact-python
j
Hello Pact team, I am getting error for hardcoded token value in
Authorization: Bearer <hardcode token>
in verification step in Buildkite pipeline before publishing pact to the pact-broker, below are the steps in our BK pipeline 1. Run consumer Contract Test and upload pact.json file to the artifacts 2. Download pact.json file 3. Verify pact with Provider 4. Publish pacts to the pact-broker Getting below error for invalid authorization as hardcoded token was passed
Copy code
Verifying a pact between cmedia-distribute-api and vmedia-mats-app
  Given get schema tag enums
    return schema tags
      with GET /metadata/schema-tag-enums
        returns a response which
          has status code 200 (FAILED - 1)
          has a matching body (FAILED - 2)
Copy code
Failure/Error: expect(response_status).to eql expected_response_status
       expected: 200
            got: 401
       (compared using eql?)
     # /pact/bin/pact:15:in `<top (required)>'
Copy code
Failure/Error: expect(response_body).to match_term expected_response_body, diff_options, example
       Actual: {"title":"Unauthorized","message":"401 Unauthorized: Invalid token: Cannot extract header,payload and signature","mats_error_code":1001}
       Diff
       --------------------------------------
       Key: - is expected 
            + is actual
m
j
Yes I did
but could not understand which one fits my use case
definitely not 5 as we don't have long lived tokens
m
Usually, I’d go with request filters. I don’t think Python has that feature (shouldn’t’ be hard to add). In your case, I’d stub the auth during provider test probably
j
My test is failing on consumer side before publishing pacts to the broker
m
The error above is from a provider verification. What’s the problem with your consumer test?
Oh, your 4 steps above makes no sense
why are you verifying the provider in step (3)? That’s the job…of the provider.
j
we have buildkite plugin which runs that for us
So you are saying publishing pact is a job of consumer but verification should happen at provider side?
m
of course!
the whole point of pact is to not having to build/test components together and remove this sort of coupling (independence)
j
I asked this to our platform team who built the plugin and they said that verify step is intentionally kept to verify pacts before publishing to the broker
Although verification is done on provider side as well
m
this is not how it’s supposed to work. You can do it, but it’s not how it’s supposed to work
what if you have more than one provider down the track?
j
yeah although plugin has a flag to make this verification as optional
so we can skip it
but in our company we use buildkite plugin
which does verification step for us
so not sure how we can stub auths as we have very little control over it
m
You’re really working against the grain here
It’s the provider team’s job to do the pact verification, and setup their code to be able to handle the various states
It’s not supposed to be a blackbox style test, it’s a white box style test that needs access to the code to work
You should go and talk to the provider team, and get them to implement a solution to the problem
j
yeah you got me right, use of that plugin might limit us
I have authority to add provider side tests
but traditionally everyone in the company uses that plugin(“black box”)
Do you have an example of python provider tests for handling authorization?
m
not off the top of my head, sorry
but I think the usually stubbing unit test tools are going to be your goto here
Might be worth searching history, I’m sure it’s come up before
j
I see there was some discussion in history about consumer_provider_header
this article deals with JS
as you said python does not have that solution
where I should request the same for python?
m
I would opt to stub out authorization, personally. To request the feature, you can raise a feature request on the github page
j
ok got it