ITV / scala-pact

A Scala implementation of CDC using the Pact standard
Other
107 stars 54 forks source link

SSL Context for Pacts #74

Closed phil-rice closed 6 years ago

phil-rice commented 6 years ago

At the company I am working for, we are now adopting pacts. We need to be able to specify the SSL Context for the pacts. This is because the scala microservices (both producers and consumers) communicate using SSL and have client side certificates. The client side certificates hold data which impacts the response

We've forked scala pact (many versions ago) and 'bodged' this in. We'd like to now do it properly and make it a pull request. Scala pact has changed quite dramatically since the version we were using, so I'd like to chat about how to do this properly

My feeling is that ideally we would be able to specify 'which' SSL context we are going to use in while making the pacts and while verifying. I'd ideally add an 'sslcontext' name in the JSON pact file, but I believe that making changes to that file format is beyond the scope of this project. An other obvious other place is provider context or description and having a parser that looks for `[sslContext=name]' in them. I'm also considering using a 'fake header'

If I do this should I start from the master branch, or is there a better branch?

Do I need to do this for all the different 'frameworks' / versions? or can I just do it for the more upto date version?

davesmith00000 commented 6 years ago

Hi Phil,

Easy stuff first:

  1. Master branch is up to date.
  2. I believe we shouldn't modify the Pact JSON format because it will be incompatible with other Pact implementations (including the broker).
  3. I would have thought this would belong in the provider state section, because it's a requirement the provider must satisfy for verification to happen?

Would it be worth you sharing your original bodged version so I can see what was involved? All that follows otherwise is pure guess work! :-)

Less easy stuff, SSL Context:

First a question: Would it be possible to do the consumer tests in vanilla http and the provider verification using SSL? Might make you're life easier if you can given that you can set the provider state, base url, protocol and port at the time you verify. No worries if not, just asking.

Either way, if I understand your requirements properly, then you'll need to supply an SSL context for Http4s to optionally make use of I think. I'm not fully sure of what you need but I'd guess that:

Consumer For the consumer tests there is actually a way to pass optional config to the test framework that, by default could not set a context but you could override it. See: https://github.com/ITV/scala-pact/blob/a07ada3671785c41afecc5090073cd7df09656df/scalapact-scalatest/src/main/scala/com/itv/scalapact/ScalaPactForger.scala#L40 and https://github.com/ITV/scala-pact/blob/a07ada3671785c41afecc5090073cd7df09656df/scalapact-scalatest/src/main/scala/com/itv/scalapact/ScalaPactForger.scala#L138

You would then need to pass that context all the way down to (yes) every version of Http4s to make use of (probably). I'm afraid there is much duplication down there, it's on my list of things to review ...sometime...

Provider My suspicion is that regardless of which method you're using to do the verification, you'll probably want to somehow add a new option to the pact verify settings (possibly) (https://github.com/ITV/scala-pact/blob/a07ada3671785c41afecc5090073cd7df09656df/scalapact-scalatest/src/main/scala/com/itv/scalapact/ScalaPactVerify.scala#L57) saying to use SSL and then some way to build the context per verification (? if it's global you could just put it right in the settings?) from a memento string in the provider state perhaps.

Please don't forget that there are two ways to verify and your solution will need to be ported to both (but I can help with that).

Show me your original version if you can and we can talk again. Otherwise, if you want to send a PR of a dirty but working version we can go from there if you like?

Cheers,

Dave

phil-rice commented 6 years ago

Thanks David,

I share your views on the JSON format, although it's interesting to consider raising this as an issue in the coordination group. We won't be the only people with certificate issues, especially as usage grows.

It's not really provider state because it's part of the request.. We actually have to include the certificate when we make the request as well as when we validate. i.e. it's not really 'provider' state at all it's actually consumer state. I started there but couldn't bring myself to do it: it just felt wrong. I've come up with a very simple idea: have a fake header. The fake header has a value which is the lookup into a map. This header is part of the request (good) is in the Json file already (good) and the data it represents is often in the real world put onto headers anyway (i.e. NGINX would rip the data out of the certificate and pass it to the end point as a header. The place in the code that does this is encapsulated in SslContextMap so if we change our mind and decide it's really provider state, it's really simple to sort it out.

The old bodged version is messy and scattered throughout our code. (we didn't really fork it we copied the files we wanted and edited them... as I say it was a bodge). It also didn't modify the json file: we were in charge of both ends. The work is pretty simple I've attached a patch which is WIP. I think it probably works: the compiler says it does. But because it's SSL certificates I'm in the middle of test pain. I just love SSL Engine Errors. The patch base was 'WIP: provider_test example does not work' . I'm not very familiar with making patches so I'm not sure if you apply it to master or to 'add script for release local'

The patch has a default implicit which (I hope: still need to test it) is threaded through the code to the point at which the connections are made. The default implicit says 'there aren't any SSL Contexts'. By setting a header in the request (which is removed from the actual HTTPS call) the pact user can do this. This feels a little clunky so when I've got this working, I might modify the builder to have a 'with ssl context' and only have the json file know about the fake header.

Just as an aside: a separate issue... Our microservices are behind an API gateway. The API gateway is responsible for things like OPTIONS requests, and also modifies the payload a bit... So when we are consuming our microservices as javascript in the browser, the JSON file we produce is guaranteeded to be unverifiable by the microservice. We split it into two using good old AWK JQ SED style of working and end up with two pacts. One for the API gateway, and one for the actual microservice. We've got a solution for this, I just though you'd be interested in the problem

@Summary I'm working on the pull request: Just need to check it actually works.

regards

Phil

On 16 November 2017 at 18:52, Dave Smith notifications@github.com wrote:

Hi Phil,

Easy stuff first:

  1. Master branch is up to date.
  2. I believe we shouldn't modify the Pact JSON format because it will be incompatible with other Pact implementations (including the broker).
  3. I would have thought this would belong in the provider state section, because it's a requirement the provider must satisfy for verification to happen?

Would it be worth you sharing your original bodged version so I can see what was involved? All that follows otherwise is pure guess work! :-)

Less easy stuff, SSL Context:

First a question: Would it be possible to do the consumer tests in vanilla http and the provider verification using SSL? Might make you're life easier if you can given that you can set the provider state, base url, protocol and port at the time you verify. No worries if not, just asking.

Either way, if I understand your requirements properly, then you'll need to supply an SSL context for Http4s to optionally make use of I think. I'm not fully sure of what you need but I'd guess that:

Consumer For the consumer tests there is actually a way to pass optional config to the test framework that, by default could not set a context but you could override it. See: https://github.com/ITV/scala-pact/blob/a07ada3671785c41afecc5090073cd 7df09656df/scalapact-scalatest/src/main/scala/com/ itv/scalapact/ScalaPactForger.scala#L40 and https://github.com/ITV/scala-pact/blob/a07ada3671785c41afecc5090073cd 7df09656df/scalapact-scalatest/src/main/scala/com/ itv/scalapact/ScalaPactForger.scala#L138

You would then need to pass that context all the way down to (yes) every version of Http4s to make use of (probably). I'm afraid there is much duplication down there, it's on my list of things to review ...sometime...

Provider My suspicion is that regardless of which method you're using to do the verification, you'll probably want to somehow add a new option to the pact verify settings (possibly) (https://github.com/ITV/scala-pact/blob/ a07ada3671785c41afecc5090073cd7df09656df/scalapact- scalatest/src/main/scala/com/itv/scalapact/ScalaPactVerify.scala#L57) saying to use SSL and then some way to build the context per verification (? if it's global you could just put it right in the settings?) from a memento string in the provider state perhaps.

Please don't forget that there are two ways to verify and your solution will need to be ported to both (but I can help with that).

Show me your original version if you can and we can talk again. Otherwise, if you want to send a PR of a dirty but working version we can go from there if you like?

Cheers,

Dave

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ITV/scala-pact/issues/74#issuecomment-345004161, or mute the thread https://github.com/notifications/unsubscribe-auth/AART8hQh-tZ_aKkB1tAazX0o6nRMLOu-ks5s3HZOgaJpZM4QgIYl .

-- Stuff our lawyer makes us say:

Index: example/provider/delivered_pacts/Consumer_Provider.json IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8

--- example/provider/delivered_pacts/Consumer_Provider.json (date 1510221100000) +++ example/provider/delivered_pacts/Consumer_Provider.json (date 1510587421000) @@ -7,25 +7,6 @@ }, "interactions" : [ {

+import cats.effect. +import io.circe.generic.auto. +import io.circe.syntax. import org.http4s. -import org.http4s.dsl._ -import root.argonaut. -import Argonaut. -import org.http4s.argonaut._

+import org.http4s.circe. +import org.http4s.dsl.io. import org.http4s.util.CaseInsensitiveString

object Provider {

@@ -23,7 +20,7 @@ val nameHeader = request.headers.get(CaseInsensitiveString("Name")).map(_.value)

   (acceptHeader, nameHeader) match {

@@ -40,16 +37,5 @@

}

-object ResultResponseImplicits {

+import cats.effect.IO import org.http4s.server.blaze.BlazeBuilder import org.http4s.server._

@@ -9,7 +10,7 @@ def main(args: Array[String]): Unit = {

 // Here we inject the real functions that do all the work

Index: example/provider_tests/src/test/scala/com/example/provider/VerifyContractsSpec.scala IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8

--- example/provider_tests/src/test/scala/com/example/provider/VerifyContractsSpec.scala (date 1510221100000) +++ example/provider_tests/src/test/scala/com/example/provider/VerifyContractsSpec.scala (date 1510587421000) @@ -1,14 +1,14 @@ package com.example.provider

-import org.scalatest.{FunSpec, Matchers, BeforeAndAfterAll} +import cats.effect.IO +import org.scalatest.{BeforeAndAfterAll, FunSpec, Matchers} import org.http4s.server.Server

import com.itv.scalapact.ScalaPactVerify._

class VerifyContractsSpec extends FunSpec with Matchers with BeforeAndAfterAll {

// Their are almost certainly nicer ways to do this.

@@ -165,7 +165,7 @@

}

+import javax.net.ssl.SSLContext + import com.itv.scalapact.shared.{SimpleRequest, SimpleResponse} import org.http4s.{BuildInfo, Response} import org.http4s.client.Client @@ -13,21 +15,22 @@

import HeaderImplicitConversions._

-import com.itv.scalapact.shared.{SimpleRequest, SimpleResponse} +import javax.net.ssl.SSLContext + +import com.itv.scalapact.shared.{SimpleRequest, SimpleResponse, SslContextMap} import org.http4s.{BuildInfo, Response} import org.http4s.client.Client import org.http4s.client.blaze.{BlazeClientConfig, PooledHttp1Client} @@ -13,20 +15,21 @@

import HeaderImplicitConversions._

+import javax.net.ssl.SSLContext + import com.itv.scalapact.shared.{SimpleRequest, SimpleResponse} import fs2.{Strategy, Task} import org.http4s.client.Client @@ -16,8 +18,9 @@

private[http] implicit val strategy: Strategy = fs2.Strategy.fromFixedDaemonPool(2, threadName = "strategy")

@@ -63,8 +63,9 @@

def combineProviderStatesIntoTotalFunction(directPactStates: Seq[(String, String => Boolean)], patternMatchedStates: PartialFunction[String, Boolean]): String => Boolean = { val l = directPactStates

+import com.itv.scalapact.shared.SslContextMap + import scala.language.implicitConversions import scala.util.Properties

@@ -37,7 +39,7 @@ */ def addInteraction(interaction: ScalaPactInteraction): ScalaPactDescription = new ScalaPactDescription(consumer, provider, interactions ++ List(interaction))

@@ -82,7 +82,7 @@ waitForServerThenTest(server, mockConfig, test, pactDescription) }

-import com.itv.scalapact.shared.{Helpers, ScalaPactSettings} +import com.itv.scalapact.shared.{Helpers, ScalaPactSettings, SslContextMap} import com.itv.scalapactcore.common.PactReaderWriter._

import scala.concurrent.duration._ @@ -15,14 +15,14 @@

object verifyPact {

Index: scalapact-shared/src/main/scala/com/itv/scalapact/shared/IScalaPactHttpClient.scala IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8

--- scalapact-shared/src/main/scala/com/itv/scalapact/shared/IScalaPactHttpClient.scala (date 1508775849000) +++ scalapact-shared/src/main/scala/com/itv/scalapact/shared/IScalaPactHttpClient.scala (date 1510827601000) @@ -5,11 +5,11 @@

trait IScalaPactHttpClient {

+import javax.net.ssl.SSLContext + import com.github.tomakehurst.wiremock.WireMockServer import com.github.tomakehurst.wiremock.client.WireMock import com.github.tomakehurst.wiremock.client.WireMock. import com.github.tomakehurst.wiremock.core.WireMockConfiguration. -import com.itv.scalapact.shared.{HttpMethod, SimpleRequest} +import com.itv.scalapact.shared.{HttpMethod, SimpleRequest, SslContextMap} +import org.scalatest.easymock.EasyMockSugar import org.scalatest.{BeforeAndAfterAll, FunSpec, Matchers}

class Http4sClientHelperSpec extends FunSpec with Matchers with BeforeAndAfterAll { @@ -40,7 +43,7 @@ response.body.get shouldEqual "Success" response.headers.exists(_ == ("foo" -> "bar")) shouldEqual true }

-trait IPactReader { +trait IPactReader {

type ReadPactF = String => Either[String, Pact]

Index: scalapact-shared/src/test/scala/com/itv/scalapact/shared/HelpersSpec.scala IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8

--- scalapact-shared/src/test/scala/com/itv/scalapact/shared/HelpersSpec.scala (date 1510827601000) +++ scalapact-shared/src/test/scala/com/itv/scalapact/shared/HelpersSpec.scala (date 1510904148000) @@ -10,7 +10,6 @@

   Helpers.pair(List(1, 2, 3, 4)) shouldEqual Map(1 -> 2, 3 -> 4)
   Helpers.pair(List("a", "b", "c")) shouldEqual Map("a" -> "b")

- }

 it("should be able to pair a list into a list of tuples") {

Index: scalapact-shared/src/test/scala/com/itv/scalapact/shared/SslContextMapSpec.scala IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8

--- scalapact-shared/src/test/scala/com/itv/scalapact/shared/SslContextMapSpec.scala (date 1510904148000) +++ scalapact-shared/src/test/scala/com/itv/scalapact/shared/SslContextMapSpec.scala (date 1510904148000) @@ -0,0 +1,36 @@ +package com.itv.scalapact.shared + +import javax.net.ssl.SSLContext + +import org.scalatest.easymock.EasyMockSugar +import org.scalatest.{FunSpec, Matchers} + +class SslContextMapSpec extends FunSpec with Matchers { +

phil-rice commented 6 years ago

I ended up using a header that's in SSLContextMap. This allows me to send different certificates with different interactions. It's a little clunky at pact creation time: you can only set a single ssl context for the mock server, but since (as far as I know) I can only have one ssl context for a HTTP4s server that makes sense

I have it working now. I've validated it against the code we use internally and it makes pacts, includes the ssl context as a header in the pact json. When it does pack mocking it doesn't look for the header, but in pact verification it uses it to select which certificate to use. I don't think the pact stubber uses them properly, but actually I'm not entirely sure how to do that. I'll probably phone you for a chat about it if that's OK

Do you want to look at the code, and check you are roughly OK with it. I'll add some tests for it over the next few days (I've been using the bank test suite because certificates are such a pain to work with)

On 17 November 2017 at 08:49, Phil Rice phil.rice@validoc.org wrote:

Thanks David,

I share your views on the JSON format, although it's interesting to consider raising this as an issue in the coordination group. We won't be the only people with certificate issues, especially as usage grows.

It's not really provider state because it's part of the request.. We actually have to include the certificate when we make the request as well as when we validate. i.e. it's not really 'provider' state at all it's actually consumer state. I started there but couldn't bring myself to do it: it just felt wrong. I've come up with a very simple idea: have a fake header. The fake header has a value which is the lookup into a map. This header is part of the request (good) is in the Json file already (good) and the data it represents is often in the real world put onto headers anyway (i.e. NGINX would rip the data out of the certificate and pass it to the end point as a header. The place in the code that does this is encapsulated in SslContextMap so if we change our mind and decide it's really provider state, it's really simple to sort it out.

The old bodged version is messy and scattered throughout our code. (we didn't really fork it we copied the files we wanted and edited them... as I say it was a bodge). It also didn't modify the json file: we were in charge of both ends. The work is pretty simple I've attached a patch which is WIP. I think it probably works: the compiler says it does. But because it's SSL certificates I'm in the middle of test pain. I just love SSL Engine Errors. The patch base was 'WIP: provider_test example does not work' . I'm not very familiar with making patches so I'm not sure if you apply it to master or to 'add script for release local'

The patch has a default implicit which (I hope: still need to test it) is threaded through the code to the point at which the connections are made. The default implicit says 'there aren't any SSL Contexts'. By setting a header in the request (which is removed from the actual HTTPS call) the pact user can do this. This feels a little clunky so when I've got this working, I might modify the builder to have a 'with ssl context' and only have the json file know about the fake header.

Just as an aside: a separate issue... Our microservices are behind an API gateway. The API gateway is responsible for things like OPTIONS requests, and also modifies the payload a bit... So when we are consuming our microservices as javascript in the browser, the JSON file we produce is guaranteeded to be unverifiable by the microservice. We split it into two using good old AWK JQ SED style of working and end up with two pacts. One for the API gateway, and one for the actual microservice. We've got a solution for this, I just though you'd be interested in the problem

@Summary I'm working on the pull request: Just need to check it actually works.

regards

Phil

On 16 November 2017 at 18:52, Dave Smith notifications@github.com wrote:

Hi Phil,

Easy stuff first:

  1. Master branch is up to date.
  2. I believe we shouldn't modify the Pact JSON format because it will be incompatible with other Pact implementations (including the broker).
  3. I would have thought this would belong in the provider state section, because it's a requirement the provider must satisfy for verification to happen?

Would it be worth you sharing your original bodged version so I can see what was involved? All that follows otherwise is pure guess work! :-)

Less easy stuff, SSL Context:

First a question: Would it be possible to do the consumer tests in vanilla http and the provider verification using SSL? Might make you're life easier if you can given that you can set the provider state, base url, protocol and port at the time you verify. No worries if not, just asking.

Either way, if I understand your requirements properly, then you'll need to supply an SSL context for Http4s to optionally make use of I think. I'm not fully sure of what you need but I'd guess that:

Consumer For the consumer tests there is actually a way to pass optional config to the test framework that, by default could not set a context but you could override it. See: https://github.com/ITV/scala-pact/blob/a07ada3671785c41afecc 5090073cd7df09656df/scalapact-scalatest/src/main/scala/com/i tv/scalapact/ScalaPactForger.scala#L40 and https://github.com/ITV/scala-pact/blob/a07ada3671785c41afecc 5090073cd7df09656df/scalapact-scalatest/src/main/scala/com/i tv/scalapact/ScalaPactForger.scala#L138

You would then need to pass that context all the way down to (yes) every version of Http4s to make use of (probably). I'm afraid there is much duplication down there, it's on my list of things to review ...sometime...

Provider My suspicion is that regardless of which method you're using to do the verification, you'll probably want to somehow add a new option to the pact verify settings (possibly) (https://github.com/ITV/scala- pact/blob/a07ada3671785c41afecc5090073cd7df09656df/ scalapact-scalatest/src/main/scala/com/itv/scalapact/ ScalaPactVerify.scala#L57) saying to use SSL and then some way to build the context per verification (? if it's global you could just put it right in the settings?) from a memento string in the provider state perhaps.

Please don't forget that there are two ways to verify and your solution will need to be ported to both (but I can help with that).

Show me your original version if you can and we can talk again. Otherwise, if you want to send a PR of a dirty but working version we can go from there if you like?

Cheers,

Dave

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ITV/scala-pact/issues/74#issuecomment-345004161, or mute the thread https://github.com/notifications/unsubscribe-auth/AART8hQh-tZ_aKkB1tAazX0o6nRMLOu-ks5s3HZOgaJpZM4QgIYl .

-- Stuff our lawyer makes us say:

  • This isn't a contract, it's just a chat
  • This is confidential: If you get this, and you shouldn't, please tell me

-- Stuff our lawyer makes us say:

Index: example/provider/delivered_pacts/Consumer_Provider.json IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8

--- example/provider/delivered_pacts/Consumer_Provider.json (date 1510221100000) +++ example/provider/delivered_pacts/Consumer_Provider.json (date 1510587421000) @@ -7,25 +7,6 @@ }, "interactions" : [ {

+import cats.effect. +import io.circe.generic.auto. +import io.circe.syntax. import org.http4s. -import org.http4s.dsl._ -import root.argonaut. -import Argonaut. -import org.http4s.argonaut._

+import org.http4s.circe. +import org.http4s.dsl.io. import org.http4s.util.CaseInsensitiveString

object Provider {

@@ -23,7 +20,7 @@ val nameHeader = request.headers.get(CaseInsensitiveString("Name")).map(_.value)

   (acceptHeader, nameHeader) match {

@@ -40,16 +37,5 @@

}

-object ResultResponseImplicits {

+import cats.effect.IO import org.http4s.server.blaze.BlazeBuilder import org.http4s.server._

@@ -9,7 +10,7 @@ def main(args: Array[String]): Unit = {

 // Here we inject the real functions that do all the work

Index: example/provider_tests/src/test/scala/com/example/provider/VerifyContractsSpec.scala IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8

--- example/provider_tests/src/test/scala/com/example/provider/VerifyContractsSpec.scala (date 1510221100000) +++ example/provider_tests/src/test/scala/com/example/provider/VerifyContractsSpec.scala (date 1510587421000) @@ -1,14 +1,14 @@ package com.example.provider

-import org.scalatest.{FunSpec, Matchers, BeforeAndAfterAll} +import cats.effect.IO +import org.scalatest.{BeforeAndAfterAll, FunSpec, Matchers} import org.http4s.server.Server

import com.itv.scalapact.ScalaPactVerify._

class VerifyContractsSpec extends FunSpec with Matchers with BeforeAndAfterAll {

// Their are almost certainly nicer ways to do this.

@@ -120,24 +120,24 @@

       val success = ps.f(ps.key)

Index: scalapact-http4s-0-15-0a/src/main/scala/com/itv/scalapact/shared/http/Http4sClientHelper.scala IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8

--- scalapact-http4s-0-15-0a/src/main/scala/com/itv/scalapact/shared/http/Http4sClientHelper.scala (date 1508775849000) +++ scalapact-http4s-0-15-0a/src/main/scala/com/itv/scalapact/shared/http/Http4sClientHelper.scala (date 1510827601000) @@ -1,5 +1,7 @@ package com.itv.scalapact.shared.http

+import javax.net.ssl.SSLContext + import com.itv.scalapact.shared.{SimpleRequest, SimpleResponse} import org.http4s.{BuildInfo, Response} import org.http4s.client.Client @@ -13,21 +15,22 @@

import HeaderImplicitConversions._

-import com.itv.scalapact.shared.{SimpleRequest, SimpleResponse} +import javax.net.ssl.SSLContext + +import com.itv.scalapact.shared.{SimpleRequest, SimpleResponse, SslContextMap} import org.http4s.{BuildInfo, Response} import org.http4s.client.Client import org.http4s.client.blaze.{BlazeClientConfig, PooledHttp1Client} @@ -13,20 +15,21 @@

import HeaderImplicitConversions._

+import javax.net.ssl.SSLContext + import com.itv.scalapact.shared.{SimpleRequest, SimpleResponse} import fs2.{Strategy, Task} import org.http4s.client.Client @@ -16,8 +18,9 @@

private[http] implicit val strategy: Strategy = fs2.Strategy.fromFixedDaemonPool(2, threadName = "strategy")

Index: scalapact-scalatest/src/main/scala/com/itv/scalapact/ScalaPactForger.scala IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8

--- scalapact-scalatest/src/main/scala/com/itv/scalapact/ScalaPactForger.scala (date 1508775849000) +++ scalapact-scalatest/src/main/scala/com/itv/scalapact/ScalaPactForger.scala (date 1511222031000) @@ -1,11 +1,14 @@ package com.itv.scalapact

+import com.itv.scalapact.shared.SslContextMap + import scala.language.implicitConversions import scala.util.Properties

object ScalaPactForger {

implicit def toOption[A](a: A): Option[A] = Option(a) + implicit def rulesToOptionalList(rules: ScalaPactForger.ScalaPactMatchingRules): Option[List[ScalaPactForger.ScalaPactMatchingRule]] = Option(rules.rules)

@@ -25,23 +28,27 @@ def between(consumer: String): ScalaPartialPact = new ScalaPartialPact(consumer)

 class ScalaPartialPact(consumer: String) {

@@ -114,6 +114,6 @@

}

-case class ScalaPactMockConfig(protocol: String, host: String, port: Int, outputPath: String) { +case class ScalaPactMockConfig(protocol: String, host: String, port: Int, outputPath: String, sslContextName: Option[String]) { val baseUrl: String = protocol + "://" + host + ":" + port.toString } Index: scalapact-scalatest/src/main/scala/com/itv/scalapact/ScalaPactVerify.scala IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8

--- scalapact-scalatest/src/main/scala/com/itv/scalapact/ScalaPactVerify.scala (date 1508775849000) +++ scalapact-scalatest/src/main/scala/com/itv/scalapact/ScalaPactVerify.scala (date 1511222031000) @@ -4,7 +4,7 @@ import com.itv.scalapactcore.verifier.{PactVerifySettings, Verifier, VersionedConsumer} import java.io.{BufferedWriter, File, FileWriter}

-import com.itv.scalapact.shared.{Helpers, ScalaPactSettings} +import com.itv.scalapact.shared.{Helpers, ScalaPactSettings, SslContextMap} import com.itv.scalapactcore.common.PactReaderWriter._

import scala.concurrent.duration._ @@ -15,14 +15,14 @@

object verifyPact {

davesmith00000 commented 6 years ago

Hi Phil, I'll send you an email.

davesmith00000 commented 6 years ago

Merged and released in version 2.2.2.