HttpClient 4.1.1 retourne 401 lors de l'authentification avec NTLM, navigateurs, beau travail

Je suis en train d'utiliser Apache/Jakarta HttpClient 4.1.1 pour se connecter à un arbitraire de la page web à l'aide de la donnée d'identification. Pour tester cela, j'ai une installation minimale d'IIS 7.5 sur ma machine de dev de course où un seul mode d'authentification est actif à la fois. L'authentification de base fonctionne très bien, mais Digest et NTLM retour 401 messages d'erreur à chaque fois que j'essaie de me connecter. Voici mon code:

    DefaultHttpClient httpclient = new DefaultHttpClient();
    HttpContext localContext = new BasicHttpContext();
    HttpGet httpget = new HttpGet("http://localhost/"); 
    CredentialsProvider credsProvider = new BasicCredentialsProvider();
    credsProvider.setCredentials(AuthScope.ANY,
            new NTCredentials("user", "password", "", "localhost"));
    if (!new File(System.getenv("windir") + "\\krb5.ini").exists()) {
        List<String> authtypes = new ArrayList<String>();
        authtypes.add(AuthPolicy.NTLM);
        authtypes.add(AuthPolicy.DIGEST);
        authtypes.add(AuthPolicy.BASIC);
        httpclient.getParams().setParameter(AuthPNames.PROXY_AUTH_PREF,
                authtypes);
        httpclient.getParams().setParameter(AuthPNames.TARGET_AUTH_PREF,
                authtypes);
    }
    localContext.setAttribute(ClientContext.CREDS_PROVIDER, credsProvider);
    HttpResponse response = httpclient.execute(httpget, localContext);
    System.out.println("Response code: " + response.getStatusLine());

La seule chose que j'ai remarqué dans un violon, c'est que les hachages envoyé par Firefox par rapport à HttpClient sont différents, me faisant penser que peut-être IIS 7.5 attend plus fort de hachage que HttpClient? Des idées? Ce serait génial si je pouvais vérifier que ce serait de travailler avec NTLM. Digest serait sympa aussi, mais je ne peux vivre sans que, si nécessaire.

J'ai eu l'authentification Digest pour travailler dans les navigateurs, mais il montre encore 401 interdit dans HttpClient. Je suis perplexe.
Le code fonctionne pour moi, mais c'est déconseillé en 4.3. Je ne peux pas trouver un guide clair à utiliser pur 4.3 code.

OriginalL'auteur Jesse | 2011-05-06

9

Je ne suis pas un expert sur le sujet, mais au cours de l'authentification NTLM à l'aide de http composants, j'ai vu que le client a besoin de 3 tentatives pour se connecter à un NTML point de terminaison dans mon cas. Elle est un peu décrit ici pour Spnego mais c'est un peu différent pour l'authentification NTLM.

Pour NTLM dans la première tentative, le client devra faire une demande auprès de Target auth state: UNCHALLENGED et le serveur Web renvoie une erreur HTTP 401 statut et un en-tête: WWW-Authenticate: NTLM

Client vérifie la configuration de systèmes d'Authentification, NTLM doit être configuré dans le code client.

Deuxième tentative, le client devra faire une demande auprès de Target auth state: CHALLENGED, et envoie un en-tête d'autorisation avec un jeton encodés en base64 format: Authorization: NTLM TlRMTVNTUAABAAAAAYIIogAAAAAoAAAAAAAAACgAAAAFASgKAAAADw==
Serveur renvoie une erreur HTTP 401 statut, mais l'en-tête: WWW-Authenticate: NTLM maintenant est rempli avec les informations codées.

3ème Tentative Client utilise les informations de WWW-Authenticate: NTLM en-tête et fera de la demande finale avec Target auth state: HANDSHAKE et d'une autorisation de l'en-tête Authorization: NTLM qui contient plus d'informations pour le serveur.

Dans mon cas, j'ai un message d' HTTP/1.1 200 OK après.

Afin d'éviter tout cela, dans chaque demande la documentation au chapitre 4.7.1 les états que la même exécution jeton doit être utilisé pour la logique des demandes. Pour moi, il n'a pas travaillé.

Mon code:
J'initialise le client, une fois dans un @PostConstruct méthode d'un EJB
```
        PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager();
        cm.setMaxTotal(18);
        cm.setDefaultMaxPerRoute(6);

        RequestConfig requestConfig = RequestConfig.custom()
        .setSocketTimeout(30000)
        .setConnectTimeout(30000)
        .setTargetPreferredAuthSchemes(Arrays.asList(AuthSchemes.NTLM))
        .setProxyPreferredAuthSchemes(Arrays.asList(AuthSchemes.BASIC))
        .build();

        CredentialsProvider credentialsProvider = new BasicCredentialsProvider();
        credentialsProvider.setCredentials(AuthScope.ANY,
                new NTCredentials(userName, password, hostName, domainName));

        //Finally we instantiate the client. Client is a thread safe object and can be used by several threads at the same time. 
        //Client can be used for several request. The life span of the client must be equal to the life span of this EJB.
         this.httpclient = HttpClients.custom()
        .setConnectionManager(cm)
        .setDefaultCredentialsProvider(credentialsProvider)
        .setDefaultRequestConfig(requestConfig)
        .build();
```
Utiliser la même instance de client à chaque demande:
```
            HttpPost httppost = new HttpPost(endPoint.trim());            
            //HttpClientContext is not thread safe, one per request must be created.
            HttpClientContext context = HttpClientContext.create();    
            response = this.httpclient.execute(httppost, context);
```
De libérer les ressources et le retour de la connexion dans le gestionnaire de connexion, à l' @PreDestroy méthode de mon EJB:
```
             this.httpclient.close();
```
OriginalL'auteur gazgas

J'ai eu le même problème avec HttpClient4.1.X Après la mise à niveau à
HttpClient 4.2.6 il woked comme un charme. Ci-dessous mon code

DefaultHttpClient httpclient = new DefaultHttpClient();
        HttpContext localContext = new BasicHttpContext();
        HttpGet httpget = new HttpGet("url"); 
        CredentialsProvider credsProvider = new BasicCredentialsProvider();
        credsProvider.setCredentials(AuthScope.ANY,
                new NTCredentials("username", "pwd", "", "domain"));
                    List<String> authtypes = new ArrayList<String>();
            authtypes.add(AuthPolicy.NTLM);      
            httpclient.getParams().setParameter(AuthPNames.TARGET_AUTH_PREF,authtypes);

        localContext.setAttribute(ClientContext.CREDS_PROVIDER, credsProvider);
        HttpResponse response = httpclient.execute(httpget, localContext);
        HttpEntity entity=response.getEntity();

Ce code a fonctionné pour moi avec la version 4.2.2... Cheers !!!
Cela a fonctionné pour moi.

OriginalL'auteur Mohammed Irfan Tirupattur

3

J'ai eu un problème similaire avec HttpClient 4.1.2. Pour moi, il a été résolu par un retour à la HttpClient 4.0.3. Je n'ai jamais pu obtenir NTLM de travail avec 4.1.2 utilisant le construit-dans la mise en œuvre ou à l'aide de JCIFS.

Juste une remarque, j'ai rencontré ce même problème. Le httpclient 4.2.3 libération affirme avoir rafraîchis NTLM mise en œuvre. J'ai trouvé que la mise à niveau vers 4.2.3 fonctionné sans problème en ce qui concerne l'authentification NTLM.

OriginalL'auteur Jeff Nadler
2

Le moyen le plus facile à résoudre de telles situations que j'ai trouvé est Wireshark. C'est un très gros marteau, mais il va vraiment vous montrer tout. L'installer, assurez-vous que votre serveur est sur une autre machine (ne fonctionne pas avec Localhost) et démarrer l'enregistrement.

Exécuter votre requête échoue, exécutez l'une qui fonctionne. Ensuite, filtrer par http (juste mettre l'adresse http dans le champ de filtre), de trouver la première demande, la demande d'OBTENIR et de comparer. Identifier différence significative, vous avez maintenant des mots clés spécifiques ou des questions de code de la recherche/net. Si pas assez, étroit vers le bas de la première TCP conversation et de regarder plein de requête/réponse. De même pour l'autre.

J'ai résolu un nombre incroyable de problèmes avec cette approche. Et Wireshark est outil très utile à savoir. Beaucoup de super-fonctions avancées pour rendre votre réseau de débogage plus facile.

Vous pouvez également l'exécuter sur le client ou le serveur. Ce qui te permettra de vous montrer à la fois demandes pour vous permettre de comparer.

OriginalL'auteur Alexandre Rafalovitch
2

Mise à jour de notre application pour utiliser les petits pots dans le httpcomponents-client-4.5.1 résolu ce problème pour moi.

OriginalL'auteur Andrew Plata
1

J'ai enfin compris. L'authentification Digest est que, si vous utilisez une URL complète dans la demande, le mandataire doit également utiliser l'URL complète. Je n'ai pas quitté le code proxy dans l'échantillon, mais elle a été dirigée à "localhost", qui l'a fait échouer. La modification de cette 127.0.0.1 fait le travail.

OriginalL'auteur Jesse

Vous devez vous connecter pour publier un commentaire.