[
https://issues.apache.org/jira/browse/HTTPCLIENT-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14017644#comment-14017644
]
Sebb edited comment on HTTPCLIENT-1449 at 6/4/14 5:31 PM:
----------------------------------------------------------
What I did was split AbstractVerifier into AbstractBaseHostnameVerifier and
AbstractCommonHostnameVerifier the former implementing cert extraction logic
while the latter implementing CN and SubjectAlts extraction and validation
logic. The #verify methods are still final but one can now subclass
AbstractBaseHostnameVerifier and implement cert verification by delegating to
another X509HostnameVerifier instance.
I hope this is good enough.
Oleg
was (Author: olegk):
What I did was split AbstractVerifier into AbstractBaseHostnameVerifier and
AbstractCommonHostnameVerifier the former implementing cert extraction logic
while the latter implementing CN and SubjectAlts extraction and validation
logic. The #verify methods are still final but one can know subclass
AbstractBaseHostnameVerifier and implement cert verification by delegating to
another X509HostnameVerifier instance.
I hope this is good enough.
Oleg
> X509HostnameVerifier API is too restrictive
> -------------------------------------------
>
> Key: HTTPCLIENT-1449
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1449
> Project: HttpComponents HttpClient
> Issue Type: Wish
> Affects Versions: 4.3.1
> Reporter: Mikhail Golubev
> Priority: Minor
> Fix For: 4.4 Alpha1
>
>
> I want to customize hostname verification process by creating custom
> X509HostnameVerifier, which first try to use BrowserCompatHostnameVerifier
> strategy to check hostname and then, if it fails, asks user directly, whether
> such certificate can be accepted. As I understand, this verifier then can be
> supplied to e.g. HttpClientBuilder#setHostnameVerifier.
> But how should I achieve this? I can't extend BrowserCompatHostnameVerifier,
> because all its methods is final or package-private. Extending
> AbstractVerifier also makes no sense, because its only overridable method is
> verify(String, String[], String[]) and it gives me no access to certificate
> itself, which I need for user dialog. On the other hand, method verify(String
> host, X509Certificate cert) is the perfect extension point for me, but it's
> declared final. I really don't like to implement X509HostnameVerifier and
> then copy half of the AbstractVerifier in it. May be I'm missing some other
> way to intercept hostname verification?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
