Client HTTP Apache 4.3 informations d'identification par requête

J'ai eu un coup d'oeil à une authentification digest exemple:

http://hc.apache.org/httpcomponents-client-4.3.x/examples.html

Dans mon scénario, il y a plusieurs threads émettre des requêtes HTTP, et chacun d'eux doit être authentifié avec leur propre ensemble d'informations d'identification. En outre, veuillez considérer cette question est sans doute très spécifiques pour le client HTTP Apache 4.3 partir, 4.2 gère l'authentification probablement d'une manière différente, bien que je n'ai pas vérifier moi-même. Cela dit, il y va de la question.

Je veux juste utiliser une instance de client (membre statique de la classe, qui est thread-safe) et lui donner un gestionnaire de connexion à l'appui de plusieurs demandes simultanées. Le point est que chaque demande de fournir des informations d'identification différentes et je ne vois pas le moyen d'attribuer les informations d'identification, conformément à la demande que les informations d'identification fournisseur est défini lors de la construction de la client http. À partir du lien ci-dessus:

[...]

    HttpHost targetHost = new HttpHost("localhost", 80, "http");
    CredentialsProvider credsProvider = new BasicCredentialsProvider();
    credsProvider.setCredentials(
            new AuthScope(targetHost.getHostName(), targetHost.getPort()),
            new UsernamePasswordCredentials("username", "password"));
    CloseableHttpClient httpclient = HttpClients.custom()
            .setDefaultCredentialsProvider(credsProvider).build();

[...]

Vérification:

http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html#d5e600

L'exemple de code au point 4.4 (chercher 4.4. L'authentification HTTP et le contexte d'exécution), semble dire que la HttpClientContext est donné la auth-cache et les données d'identification du fournisseur et est ensuite passé à la requête HTTP. À côté de la requête est exécutée et il semble que le client devra obtenir les informations d'identification de filtrage par l'hôte dans la requête HTTP. En d'autres termes: si le contexte (ou le cache) dispose d'informations d'identification valides pour les cibles de l'hôte actuel de la requête HTTP, il va les utiliser. Le problème pour moi est que les différents threads d'effectuer différentes demandes pour le même hôte.

Est-il de toute façon à fournir des informations d'identification par requête HTTP?

Merci d'avance pour votre temps! 🙂

source d'informationauteur Francisco Carriedo Scher

  1. 13

    Le problème pour moi est que les différents threads d'effectuer différentes demandes pour le même hôte.

    Pourquoi cela devrait-il être un problème? Aussi longtemps que vous utilisez une autre instance HttpContext par thread, contextes d'exécution de ces fils va être complètement indepenent

    CloseableHttpClient httpclient = HttpClients.createDefault();
CredentialsProvider credentialsProvider = new BasicCredentialsProvider();
credentialsProvider.setCredentials(AuthScope.ANY, new UsernamePasswordCredentials("user:pass"));
HttpClientContext localContext = HttpClientContext.create();
localContext.setCredentialsProvider(credentialsProvider);

HttpGet httpget = new HttpGet("http://localhost/");

CloseableHttpResponse response = httpclient.execute(httpget, localContext);
try {
    EntityUtils.consume(response.getEntity());
} finally {
    response.close();
}
  2. 0

    J'ai un problème similaire.

    Je dois appeler n fois un service avec un seul système de l'utilisateur, authentifié avec NTLM. Je veux le faire en utilisant plusieurs threads.
    Ce que j'ai trouvé est de créer une seule HTTPClient sans défaut fournisseur d'informations d'identification. Lorsqu'une demande doit être effectuée à l'-je utiliser l'injection d'une CredentialProviderFactory dans la méthode d'exécution de la demande (dans un thread spécifique). L'utilisation de ce je obtenir une nouvelle marque CredentialsProvider et j'ai mis cela dans un Contexte (créé dans le fil).
    Puis-je appeler la méthode execute sur le client en utilisant la surcharge execute(method, context).

    class MilestoneBarClient implements IMilestoneBarClient {

private static final Logger log = LoggerFactory.getLogger(MilestoneBarClient.class);
private MilestoneBarBuilder builder;
private CloseableHttpClient httpclient;
private MilestoneBarUriBuilder uriBuilder;
private ICredentialsProviderFactory credsProviderFactory;


MilestoneBarClient(CloseableHttpClient client, ICredentialsProviderFactory credsProviderFactory, MilestoneBarUriBuilder uriBuilder) {
    this(client, credsProviderFactory, uriBuilder, new MilestoneBarBuilder());
}

MilestoneBarClient(CloseableHttpClient client, ICredentialsProviderFactory credsProviderFactory, MilestoneBarUriBuilder uriBuilder, MilestoneBarBuilder milestoneBarBuilder) {
    this.credsProviderFactory = credsProviderFactory;
    this.uriBuilder = uriBuilder;
    this.builder = milestoneBarBuilder;
    this.httpclient = client;
}

//This method is called by multiple threads
@Override
public MilestoneBar get(String npdNumber) {
    log.debug("Asking milestone bar info for {}", npdNumber);

    try {
        String url = uriBuilder.getPathFor(npdNumber);
        log.debug("Building request for URL {}", url);
        HttpClientContext localContext = HttpClientContext.create();
        localContext.setCredentialsProvider(credsProviderFactory.create());

        HttpGet httpGet = new HttpGet(url);

        long start = System.currentTimeMillis();
        try(CloseableHttpResponse resp = httpclient.execute(httpGet, localContext)){
[...]

    Pour certaines raisons, j'ai parfois une erreur, mais je suppose que c'est une NTLMCredentials question (qui n'est pas thread-safe...).

    Dans votre cas, vous pourriez probablement passer l'usine pour les méthodes get au lieu de passer dans la création.