Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Allow use of custom HostnameVerifier on clients. #1664
While the improvements to TLS configuration of HTTP clients in 1.0.0
You used to be able to do e.g. as:
JerseyClientConfiguration myJerseyClientConfiguration = ;
You can still do it by creating a custom Apache
This change restores the ability to set a custom HostnameVerifier
referenced this pull request
Aug 2, 2016
I think you could mark the method
HostnameVerifier customVerifier = (s, sslSession) -> false; Registry<ConnectionSocketFactory> configuredRegistry = builder .using(customVerifier) .createConfiguredRegistry();
Then we could retrieve the SSL socket factory from the registry and extract the verifier from it via reflection. Something like that:
SSLConnectionSocketFactory socketFactory = (SSLConnectionSocketFactory) configuredRegistry.lookup("https"); final Field hostnameVerifierField = FieldUtils.getField(SSLConnectionSocketFactory.class, "hostnameVerifier", true);
Thanks for the feedback @arteam I've made your suggested changes and implemented additional unit test coverage following your suggested pattern.
I ummed and ahhed over the DropwizardSSLConnectionSocketFactory constructor unit test using reflection to check private field value but I liked using a getter for the verifier field on this class even less since it would imply getter for tlsConfiguration field for consistency which exposes that to internal modification which implies need for immutable TlsConfiguration .... Also, the getter would've needed to be public rather than package protected since unit test is in a different package.
I have also squashed my commits.