https://pact.io logo
Join Slack
Powered by
Hello everyone. Might be missing something simple,...
# pactflow
m
Hello everyone. Might be missing something simple, is it possible to override authentication on stubs to make them publicly available ? We are using 
Bearer token Authentication
for our own application and it is conflicting with stubs 
authentication header
. Or maybe at least I can specify custom header to use for pact-flow authentication instead of using common 
Authentication
header.
m
šŸ‘‹
Thanks Maxim. Itā€™s something for us to think about. I believe initially we had no authentication on it but received feedback that we should enable the default auth due to security concerns. I have some ideas, would be keen for your perspective
1. Use a separate auth header for Pactflow (e.g. 
Pactflow-Authentication
)
2. Disable auth altogether (or have the option to do so as e.g. a system preference)
3. Pass through the Pactflow bearer token to the stub also (two birds with one stone).
4. Allow users to specify their own custom authentication token (e.g. continue to allow your Bearer token, but the token is user defined and checked by Pactflow). I believe this is how SwaggerHub auto-mock works
t
With option 4 you could easily implement option 3
m
Not sure I understand option 3. Option 4 wouldnā€™t work for us as we have different tokens we use for testing different user roles. For example, if user tries to perform admin action they will get 403
Option 1 is probably the most straightforward - we would just add extra header when running in test env. Though, 
pact-js
might need to be updated to exclude this header somehow?
t
Option 3 is that the pactflow token (which you probably use in your CI already) would be valid as an auth token for the stubs
āœ… 1
(I believe)
m
Ah right that is what we pass anyway. Wonder how would our test pick it up and pass to stub ? We are using hosted stubs as replacement for our backend so our code doesnā€™t know its pact stubs just different URL
t
I'm not certain about this, but if you don't mention a header in your test expectation, I believe the test still passes (this is potentially a problem if the presence of the header would cause your provider to fail, as verification will only use the headers you verified).
You would mock your auth provider layer so that it just returns the pactflow token. Depending on your design, this might not work for you, and is probably the driver behind option 4
m
Right, so if no changes to pact-js required as it will skip its verification option 1 would be the easiest and will require minimal changes on our side too
m
Thanks for the feedback! The 
403
use case is definitely a curveball for consideration.
t
Ah right! If you consider the auth token part of the contract (a reasonable choice, but I usually don't), then it's certainly more complex
m
Itā€™s not usually a problem, because provider states can be used as the signal for behaviour of the mock (and even then, itā€™s usually not required because the mock neednā€™t be very intelligent). But when using a pact file as a general stub server where it only receives HTTP interactions from clients (who couldnā€™t reasonably be expected to ā€œknowā€ about states etc.), itā€™s hard to disambiguate certain requests
t
Oh yeah. I don't really know how that would work
m
I donā€™t think we (Pactflow) want to go down a path where we start building intelligent mocks - that seems a slipperly slope into service virtualisation which is off the garden path for us (and SmartBear already has decent SV tools).
t
It seems like intelligent mocks would be against the general philosophy of Pact
šŸ’Æ 1
m
Iā€™ll bring this back to the team. I think there are a few ways we could improve it without ā€œdevolvingā€ into intelligent mocking, but also keeping the security of data considered
t
We are using hosted stubs as replacement for our backend
I'm curious about this use case - if it's for small tests, I would probably just mock the API client (and then use pact to assert that the mock's expectations are part of the contract). If it's for larger tests, how would you manage the provider state?
m
The use case I most often see, is using them as ā€œdumbā€ stubs for UI tests (e.g. Cypress), or as a dockerised backend in a ā€œn + 1" style integration test (I wouldnā€™t do that personally, but have seen it more than once)
(Iā€™m also keen to know more!)
m
We are using stub server with detox tests(no cypress on mobile)
šŸ‘ 1
If itā€™s for larger tests, how would you manage the provider state?
Its something we stumbled upon when we were trying to use 
pact mock
in place of real server. Amount of state permutations would grow too much. Good point though that even if we use stubs we will end up in the same situation. Hmā€¦.
šŸ‘ 1
What would be your recommendation beside - use bi-directional contracts? We are using GQL which is not supported yet by bi-directional contracts.
I literally took first recommendation from the list in pact docs
t
technically the first recommendation is "don't do this" šŸ˜‰ Although, I think that page might be a bit misleading. It doesn't mean "don't use pact if you have a UI", it means "don't drive pact through your UI" - as in, don't click the buttons to send the requests
m
We are not
ā¤ļø 1
t
it's better to separate the API client into code that doesn't know about your UI, and then test that with Pact
m
correct - exactly what we are doing
but pactflow gets in the way here šŸ˜„
t
how so?
m
with us not able to use authentiction header
see beginning of this discussion
t
right, but that's if you're using the stubs?
m
correct
t
but you don't need the stubs if you're just doing regular pact tests
m
yes, that is correct. But for our UI tests we are using stubs
and UI tests use real code which tries to send Auth header. Which is matched by ā€œlikeā€ in the contract anyway but pactflow interjects before that
I tried to move to pact-stub-server but that doesnā€™t support ā€˜v3ā€™ it seems šŸ˜•
t
aha! I understand
m
This might be easier to explain
t
Yep, got it
m
The problem with auth header is in the UI testing on trying to use Pact stub directly from pactflow
šŸ‘ 1
t
Also, nice diagram
What I do is stub the API client layer - handlers in your diagram
and use the responses in the stub as the responses I test against in the pact test
I consider the handler covered by pact, and everything else covered by the UI / unit tests. That might not work for you, depending on what you want to achieve
What diagramming tool is that? It's great
m
Borrowed from kentcdods blog - Excalidraw šŸ˜‰
With detox it might be a bit tricky as we would need to replace the whole handlers layers. There is no single entry point to handlers API its many small files
I like the idea though - will think about it
t
I talked a little bit about how to connect your pact expectations and mock objects here, around the 40 minute mark

https://www.youtube.com/watch?v=wkld_wRsTDEā–¾

I really should get around to writing that up as a blog post
m
Hmā€¦. I wonder if it would work with cypress/detox way of testing - as they are testing black box without replacing any files. The only thing we usually do in those tests is change URLs of external services to some mock implementations.
m
Sorry I'm just on the go but I wanted to drop this in: https://github.com/pact-foundation/pact-stub-server
šŸ™Œ 1
It supports v4
šŸ‘€ 1
3 Views
Open in Slack
PreviousNext
Powered by