You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In my company, we've been trying to use a Pactbroker hosted on private infrastructure, which is protected behind a Cloudflare Zero trust Gateway (using this is a hard constraint).
This means that in order to access our pactbroker from our tests (written in Kotlin, SpringBoot/Junit5) we need to set up a header like this : "cf-access-token=<CF_AUTHORIZATION_COOKIE>"
Sadly, there is no easy way to add such custom HTTP header in the @PactBroker annotation, and the header is needed in all HTTP interactions with the broker.
Here is our current solution, but I find it "hacky" and I hope there is a better and simpler way to do this?
First, I had to redefine an annotation MyPactBroker to add the customHttpHeaders option :
@PactSource(MyPactBrokerLoader.class)
@Inherited
public @interface MyPactBroker {
// The same properties as PactBroker were duplicated hereString[] customHttpHeaders() default "${pactbroker.customHttpHeaders:}";
}
And finally, we had to override PactReader#loadPactFromUrl and slightly change the implementation of DefaultPactReader#loadFile to use the new loadPactFromUrl.
(Sadly, DefaultPactReader is an object, so it cannot be extended for overrides, and we had to duplicate everything...)
fun loadPactFromUrl(
source: UrlPactSource,
options: Map<String, Any>,
http: CloseableHttpClient
): Pair<JsonValue.Object, PactSource> {
return when (source) {
is BrokerUrlSource -> {
val insecureTLS = Utils.lookupInMap(options, "insecureTLS", Boolean::class.java, false)
- val brokerClient = PactBrokerClient(source.pactBrokerUrl, options.toMutableMap(), PactBrokerClientConfig(insecureTLS = insecureTLS))+ val brokerClient = MyPactBrokerClient(source.pactBrokerUrl, options.toMutableMap(), PactBrokerClientConfig(insecureTLS = insecureTLS))
val pactResponse = brokerClient.fetchPact(source.url, source.encodePath)
pactResponse.pactFile to source.copy(attributes = pactResponse.links, options = options, tag = source.tag)
}
else -> when (val jsonResource = fetchJsonResource(http, source)) {
is Result.Ok -> if (jsonResource.value.first is JsonValue.Object) {
jsonResource.value.first.asObject()!! to jsonResource.value.second
} else {
throw UnsupportedOperationException("Was expected a JSON document, got ${jsonResource.value}")
}
is Result.Err -> throw jsonResource.error
}
}
}
Ultimately, it is a lot of duplicated code just to add one HTTP header. I believe other users will also need to add custom HTTP headers at some point.
Did I miss something already implemented?
If you feel like it could be easily solved by updating the library itself, I would be happy to open a PR myself. What do you think?
The text was updated successfully, but these errors were encountered:
In my company, we've been trying to use a Pactbroker hosted on private infrastructure, which is protected behind a Cloudflare Zero trust Gateway (using this is a hard constraint).
This means that in order to access our pactbroker from our tests (written in Kotlin, SpringBoot/Junit5) we need to set up a header like this :
"cf-access-token=<CF_AUTHORIZATION_COOKIE>"
Sadly, there is no easy way to add such custom HTTP header in the
@PactBroker
annotation, and the header is needed in all HTTP interactions with the broker.Here is our current solution, but I find it "hacky" and I hope there is a better and simpler way to do this?
customHttpHeaders
option :and use it like this:
PactBrokerLoader
with our own to redefine the functionnewPactBrokerClient
:PactBrokerClient#newHalClient
to use those new options:PactReader#loadPactFromUrl
and slightly change the implementation ofDefaultPactReader#loadFile
to use the newloadPactFromUrl
.(Sadly,
DefaultPactReader
is an object, so it cannot be extended for overrides, and we had to duplicate everything...)Ultimately, it is a lot of duplicated code just to add one HTTP header. I believe other users will also need to add custom HTTP headers at some point.
Did I miss something already implemented?
If you feel like it could be easily solved by updating the library itself, I would be happy to open a PR myself. What do you think?
The text was updated successfully, but these errors were encountered: