2015-03-23 10 views
10

HttpClient 4,3 miał trzech zmiennych statycznych org.apache.http.conn.ssl.SSLConnectionSocketFactory:apache httpclient 4.4: HostnameVerifier przejście od 4.3.x

  1. STRICT_HOSTNAME_VERIFIER
  2. BROWSER_COMPATIBLE_HOSTNAME_VERIFIER
  3. ALLOW_ALL__HOSTNAME_VERIFIER

Podczas uaktualniania zależności od wersji 4.4 z HttpClient, widzę, że wszystkie powyższe stałe są przestarzałe. Uwaga dotycząca deprecjacji w JavaDoc, wymieniona w celu użycia org.apache.http.conn.ssl.DefaultHostnameVerifier. Czytając dokumenty, zakładam, że DefaultHostnameVerifier jest bezpośrednim zamiennikiem STRICT_HOSTNAME_VERIFIER. Również ALLOW_ALL__HOSTNAME_VERIFIER jest łatwy do wdrożenia:

package org.wiztools.restclient.http; 

import javax.net.ssl.HostnameVerifier; 
import javax.net.ssl.SSLSession; 

/** 
* 
* @author subwiz 
*/ 
public class AllowAllHostnameVerifier implements HostnameVerifier { 

    @Override 
    public boolean verify(String string, SSLSession ssls) { 
     return true; 
    } 

} 

Jest subtelna różnica pomiędzy STRICT_HOSTNAME_VERIFIER i BROWSER_COMPATIBLE_HOSTNAME_VERIFIER (Z JavaDoc)

Jedyna różnica pomiędzy BROWSER_COMPATIBLE i ścisłe jest zamiennika (np "* .foo.com") z BROWSER_COMPATIBLE pasuje do wszystkich subdomen, w tym "abfoo.com".

Czy mamy łatwo dostępny weryfikator nazwy hosta dla domeny httpclient 4.4? BROWSER_COMPATIBLE

Odpowiedz

1

BrowserCompatHostnameVerifier była zasadniczo zgodna z IE 5/6. Nie jestem pewien, czy jest on zgodny z bardziej nowoczesnymi aplikacjami przeglądarki. BrowserCompatHostnameVerifier nigdy wcześniej nie istniały i nie powinny już być używane.

6

W rzeczywistości javadoc z AllowAllHostnameVerifier daje bezpośredni zamiennik dla ALLOW_ALL__HOSTNAME_VERIFIER, który jest NoopHostnameVerifier.

+0

Szukałem non-przestarzały sposób zrobić 'ALLOW_ALL_HOSTNAME_VERIFIER' a funkcja 'NoopHostnameVerifier' zadziałała. Wystarczy zastąpić drugi parametr funkcji instancją tej klasy, tak: 'SSLConnectionSocketFactory csf = new SSLConnectionSocketFactory (sslContext, new NoopHostnameVerifier());' –

4

Nie trzeba nową klasę wdrożenia dla AllowAllHostnameVerifier i nie potrzebują kolejnego wdrożenia dla BrowserCompatHostnameVerifier, wystarczy zdać instancji do nowej DefaultHostnameVerifier,

SSLConnectionSocketFactory sslsf = new SSLConnectionSocketFactory(sslcontext, new DefaultHostnameVerifier()); 

ten klasie neccesary metod weryfikacji w odniesieniu zarówno z następująca metoda podpisów

public final boolean verify(String host, SSLSession session) (Override) 

i

public final void verify(String host, X509Certificate cert) throws SSLException 

w drugiej metodzie httpcomponents robi sprawdzanie pasującymi subdomen

public final void verify(String host, X509Certificate cert) throws SSLException { 
    boolean ipv4 = InetAddressUtils.isIPv4Address(host); 
    boolean ipv6 = InetAddressUtils.isIPv6Address(host); 
    int subjectType = ((ipv4) || (ipv6)) ? 7 : 2; 
    List subjectAlts = extractSubjectAlts(cert, subjectType); 
    if ((subjectAlts != null) && (!(subjectAlts.isEmpty()))) { 
     if (ipv4) 
      matchIPAddress(host, subjectAlts); 
     else if (ipv6) 
      matchIPv6Address(host, subjectAlts); 
     else { 
      matchDNSName(host, subjectAlts, this.publicSuffixMatcher); 
     } 
    } else { 
     X500Principal subjectPrincipal = cert.getSubjectX500Principal(); 
     String cn = extractCN(subjectPrincipal.getName("RFC2253")); 
     if (cn == null) { 
      throw new SSLException("Certificate subject for <" + host + "> doesn't contain " + "a common name and does not have alternative names"); 
     } 

     matchCN(host, cn, this.publicSuffixMatcher); 
    } 
} 

przyjrzeć kodu źródłowego więcej wyjaśnień

org.apache.http.conn.ssl.DefaultHostnameVerifier

nadzieję, że to pomaga.

Powiązane problemy