Authentication tokens/step in pact.

[stefan-lz]

So at the moment we are having to modify the pact.json files before running pact. This is for inserting authentication tokens with expiry in about 2 hours into the pacts.

pacts = File.join(File.dirname(File.expand_path(__FILE__)), '../src/test/resources/pacts/*.json')
Dir.glob(pacts).each do |f|
  text = File.read(f)
  output_of_gsub = text.gsub(/\"Authorization\"\s*:\s*\".+\"/) { "\"Authorization\": \"ioof-token #{token}\"" }
  File.open(f, "w") { |file| file.puts output_of_gsub }
end

It would be good to be able to nicely insert/modify headers of the request before they are sent without modifying the pact files.

Cheers,

[uglyog]

For the Gradle Pact-JVM provider plugin, I added a callback that allows the request to be modified. See https://github.com/DiUS/pact-jvm/tree/master/pact-jvm-provider-gradle#modifying-the-requests-before-they-are-sent

[bethesque]

I feel very uncomfortable with this idea. If you can modify the request, then there is no guarantee that the actual request that the service will get will look like what gets replayed in pact:verify. Are any of the following options for you?

1. Setting the time using Timecop for both Consumer and Provider tests.
2. Making the expiry period configurable, and setting it to a very large time in the set_up of the provider state.

[bethesque]

Ron, in that scenario, the Consumer could completely miss sending the OAUTH token, and nothing in the tests would break. I understand making the request available as readonly, so that you could inspect the token, and then set up the appropriate state on the provider so that the token would work, but I feel very strongly against allowing the request to be modified.

[stefan-lz]

@bethesque, I agree that modifying the pacts make them less trustworthy.

So I guess the issue is in our current testing environment we do not have any mock or stub service when authenticating. So if we're using a real authenticator service, we need to have a real auth-token in the request.

[bethesque]

Are you executing pact:verify against a rack app, or are you using pact-provider-proxy to run pact:verify against an actual running server?

[uglyog]

@bethesque In the JVM version, the provider is running as a separate server so there is no way to setup anything in the provider. The only way to do it would use a mock server for the authentication. In our particular case we don't have control over the authentication, we don't have a mock server and the tokens are time sensitive and required to be signed with RSA keys.

I believe as framework authors we should allow people to be able to use the framework in any manner they require that is helpful to them, and not be prescriptive. So even though they may be able to shoot themselves in the foot, I say 'Happy Shooting'.

[bethesque]

Sigh. It makes me sad, but I see your point Ron.

@stefan-lz How are you verifying? With the normal Ruby pact:verify? Or against a running endpoint?

[stefan-lz]

pact:verify running on j-ruby (not sure if that matters or not) and our
provider is a jetty drop-wizard app, so we don't have any nice VCR/Timecop
options either. Cheers.

On Monday, October 6, 2014, Beth notifications@github.com wrote:

Sigh. It makes me sad, but I see your point Ron.

@stefan-lz https://github.com/stefan-lz How are you verifying? With the
normal Ruby pact:verify? Or against a running endpoint?

—
Reply to this email directly or view it on GitHub
https://github.com/realestate-com-au/pact/issues/49#issuecomment-57977345
.

Stefan Leszkiewicz

DiUS Computing Pty. Ltd.
Where Ideas Are Engineered

Phone: +61 3 9008 5400
Mobile: +61 402 62 9802

www.dius.com.au

[bethesque]

So, I've had a think about the nicest way we can allow people to shoot themselves in the foot.

Pact.provider_states_for "My Jetty DropWizard App whatever that is" do

  set_up do | interaction |
    interaction.request.headers['Authorization'] = 'some dynamic token'
  end

end

$ rake pact:verify
Note: set_up hook modified request:
{
  "headers" : {
-   "Authorization" : "original token"
+   "Authorization" : "some dynamic token" 
  }
}

The set_up hook already exists, it just needs to be modified to yield a copy of the interaction that can then be compared to the original one, and an information message logged to the screen to alert the Shooter to the fact that they are shooting themselves.

[bethesque]

So, @stefan-lz, if you want to make the above happen, I will reluctantly accept a pull request.

[bethesque]

Btw, I really think that instead, you should create a mock authentication service. This feels dirty.

[NigelThorne]

I think if something feels dirty you shouldn't do it... Leave it in a
branch.

If you wait long gone enough another option will become obvious that
satisfies this need and several others as well.
On 6 Oct 2014 21:13, "Beth" notifications@github.com wrote:

Btw, I really think that instead, you should create a mock
authentication service. This feels dirty.

—
Reply to this email directly or view it on GitHub
https://github.com/realestate-com-au/pact/issues/49#issuecomment-57997745
.

[stefan-lz]

I've written a spike getting dynamic auth tokens into the request via provider setup. The commit is here: stefan-lz@18c247a It does not include creating the diff output yet.

It's all very hacky, and probably breaks plenty of rules, so I'm not going to submit a pull request. But it works, and the tests are passing.

I particually like this line: stefan-lz@18c247a#diff-6ba38645571c7cc5e2d9ad8f717924e3R23

I'm now divided wether this is a good thing or not, and our case is quite unique. So I'm happy to close this until there is a larger pressing need for it.

[bethesque]

I don't know quite how drop wizard works, but do you have a rack app interface, or are you using pact-provider-proxy?

[bethesque]

If you are using the normal pact:verify, then you could something like this: https://gist.github.com/bethesque/203e9d2ec08f4a40d2df
No dirty hacks required!

I think there's a similar thing you could do if you are using pact-provider-proxy.