Hello we are attempting to use pact.net for investigation into creating some contract testing of some of our apis, we managed to create a couple tests with out authentication with no real issue. Now we are attempting to create tests with NTLM authentication and we are having some issues. Unfortunately I have been unable to add a custom header with a token to be recognized by the api (tried Negotiate and Authorization headers) - I just get end up getting a 401 error. I am currently using "IPactBuilderV3" from pact.net - is there any other ways to add NTLM authentication to our pact tests which pact supports?

howtoauth

Approaches to handling authentication in Pact tests: https://docs.pact.io/provider/handling_auth

☝️ hopefully this helps?

Unfortunately that does not seem to work - I have been told its using Kerberos. I can authenticate fine with c# and using cached credentials the issues is validating the pact file as in order to validate it needs to authenticate with the server

I personally completely stub the auth, as I don't really think it's part of the contract (other than you should have a token). This means my pact tests look like "with a valid token `"AUTH_TOKEN"`" and then I stub the auth parts of the provider to expect

"AUTH_TOKEN"

Thanks for the suggestions. @Timothy Jones The only criticism for this approach is that you lose accurately of the api's test . If I under stood you correct it becomes a stub testing another stub (The pact file)? Yes you could perhaps stub it out like you suggest but what if the api's body changes with no updates to the contract testing - then your tests would still pass when they sould not?

There are two things here, the contract test from system A to B, and a contract between B to the auth server. For the A to B test, the need to include auth is debatable and I generally exclude it. NTLM is also a standard so there are further questions to the value of testing that. There are also the practical issues we're discussing. I don't know how feasible it is to do with pact having never tried it. One option could be to setup a middleware on the provider that intercepts and enriches the request with the correct auth headers. Not ideal but might allow you to include it

To be clear, I'm not proposing stubbing the whole endpoint, just the auth validation. I don't consider the auth token to be part of the contract

To be clear, I’m not proposing stubbing the whole endpoint, just the auth validation. I don’t consider the auth token to be part of the contract

Ah, that’s a good point. I didn’t consider that might be how the suggestion was interpreted

this works really well if your auth token is a JWT from OpenID, since you usually outsource the validation of those to code/services that you didn't write anyway

Hi @Alasdair, as discussed…

After looking at the response from Timothy Jones - what does he mean by “Unmarshal / Marshal”? is he suggesting to compare a real request response and a pact contract manually? is there a better example you can share or create? Thanks

What Tim is saying is that he just stubs the auth part of your provider code base, so when the Pact verifier sends the request to the Provider, only the auth is stubbed out. The rest of the interaction with your Provider talks to the real controllers, models etc. You will also want to stub out any 3rd party systems so that you have a level of determinism and speed in your tests. This means you have a higher level of confidence in your Pact tests because they actually test a broader set of layers and act as a good form of integration test. eg. https://docs.pact.io/provider#stub-calls-to-downstream-systems