Pact Foundation

Yes thats correct but not as part of metadata but in the actual request

Idea is to use provider states to modify the request body

Gotcha. I think for now, I’d follow the other guidance and remove auth from the contract (see howtoauth)

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

hmm, what if the grpc request is for checking if the user is authorized but nothing else ?

Proto looks something like this

```{
		"pact:proto": "/home/service.proto",
		"pact:proto-service": "Service/Validate",
		"pact:content-type": "application/protobuf",
		"request": {
			"token": "matching(type, 'bj8qnqw9cnalksnd9qwnk1j9cjm')"
		},
		"response": {
			"valid": "matching(boolean, true)"
		}
	}```

Can you stub the service that validates the token when the verification happens?

Actually the service under test here validates the token. Its not handled by another service

I can stub the layer to mock the expected result

Is a valid token worth testing? Probably not, especially if you’re just going to replace it in the test itself anyway!

In some cases, it gets a little complicated where auth is needed to further process the request! Rewriting auth header would be helpful 

Just like how we can do in REST contracts

Yep, understand. It gets a little tricker because Go / Client language would probably have to receive a raw `[]byte` and then hand it back to the framework. But I think it’s doable

<@U5FCZAAUU> I seem to recall this being discussed somewhere but FYI. Something for us to consider in the future.