Autentisering mot proxyen har sine egne cURL-valg. Å sette CURLOPT_USERPWD for innlogging på en nettside setter ikke opp proxyens konto, og CURLOPT_HTTPAUTH bestemmer ikke autentiseringsmetoden for proxyen.

<?php
$user = 'proxy-user';
$password = getenv('PROXY_PASSWORD');
if ($password === false) {
    throw new RuntimeException('Set PROXY_PASSWORD');
}

$ch = curl_init('https://example.com/');
curl_setopt_array($ch, [
    CURLOPT_PROXY => 'http://203.0.113.10:8080',
    CURLOPT_NOPROXY => '',
    CURLOPT_PROXYUSERPWD =>
        rawurlencode($user) . ':' . rawurlencode($password),
    CURLOPT_PROXYAUTH => CURLAUTH_BASIC,
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_CONNECTTIMEOUT => 5,
    CURLOPT_TIMEOUT => 15,
]);

$body = curl_exec($ch);
if ($body === false) {
    throw new RuntimeException(curl_error($ch), curl_errno($ch));
}
echo curl_getinfo($ch, CURLINFO_RESPONSE_CODE), PHP_EOL;

Bytt dokumentasjons-IP-en og bruk påloggingsdata som er levert for den aktuelle proxyen. Basic er valgt med hensikt her; bruk metoden tjenesten støtter og har godkjent, fremfor å anta at alle endepunkter krever den.

Det kombinerte feltet har en kodingsregel

Ifølge libcurl URL-dekoder CURLOPT_PROXYUSERPWD både brukernavn og passord. Eksemplet koder hver komponent før de føyes sammen med skilletegnet. Dette er viktig når en bokstavelig prosentsekvens eller et annet spesialtegn inngår i påloggingsdataene.

Separate valg for proxyens brukernavn og passord tar verdiene direkte:

curl_setopt($ch, CURLOPT_PROXYUSERNAME, $user);
curl_setopt($ch, CURLOPT_PROXYPASSWORD, $password);

Bruk disse som alternativt format for påloggingsdata før forespørselen kjøres. Ikke bruk automatisk det kombinerte proxyfeltets dekodingsregel på CURLOPT_USERPWD; libcurl dokumenterer at de er forskjellige.

Skill mellom autentisering på de to leddene

CURLOPT_PROXYAUTH velger autentisering mot proxyen, mens CURLOPT_HTTPAUTH velger HTTP-autentisering mot målet. Trenger begge innlogging, sett opp de aktuelle valgene for hver part, i stedet for å kopiere samme påloggingsdata til begge steder.

CURLAUTH_ANY tillater forhandling og kan legge til en challenge-response-utveksling før metoden blir valgt. Det dokumenterer ikke at påloggingsdataene er riktige. Å legge til en Proxy-Authorization-header manuelt i tillegg kan forstyrre bibliotekets autentiseringshåndtering.

Basic-data sendt over en ukryptert forbindelse til proxyen beskyttes ikke av nettstedets senere TLS-tunnel. Sjekk den transporten for seg når du bestemmer hvordan en autentisert tjeneste skal brukes.

Relaterte artikler