HTTP 407 o 401: quale accesso non riesce?

Un 407 chiede di autenticarti al proxy. Un 401 chiede l’autenticazione alla risorsa di destinazione. Una richiesta può incontrarli entrambi: prima di fornire una password, individua chi la sta chiedendo.

Confronta lo stato e gli header di richiesta dell’autenticazione

Lo stato è un primo indizio essenziale, ma esamina l’intero scambio. Una pagina che mostra 407 nel testo non equivale a una vera risposta HTTP 407. Analogamente, una pagina di accesso personalizzata può restituire 200 e richiedere comunque l’autenticazione a livello applicativo.

Perché HTTPS può fallire con 407 prima di raggiungere il sito

Quando un normale proxy HTTP trasporta una richiesta HTTPS, il client gli chiede in genere prima di stabilire un tunnel CONNECT. Il proxy può richiedere autenticazione per quella richiesta CONNECT. Se non viene completata, la sessione TLS con la destinazione non è ancora stata stabilita nel tunnel: cambiare il token API del sito difficilmente risolverà questa fase.

Usa una richiesta con output dettagliato per vedere dove compare la richiesta di autenticazione:

curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/

Sostituisci il listener locale con il tuo e leggi la prima richiesta di autenticazione nel log. Un 407 durante CONNECT precede il TLS di destinazione; un successivo 401 può comparire dopo l’apertura riuscita del tunnel.

Fornisci le credenziali tramite l’interfaccia del proxy

Per un endpoint e un account forniti da un amministratore fidato, curl può negoziare lo schema di autenticazione del proxy e chiedere la password mancante:

curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/

Sostituisci endpoint e utente di esempio con i dati del servizio che sei autorizzato a usare. Specificare solo l’utente evita di inserire la password direttamente nel comando precedente. I metodi supportati possono variare in base alla build di curl e al proxy; se la negoziazione fallisce, controlla la richiesta effettiva e le capacità della build.

L’opzione di autenticazione del proxy è distinta da quella di curl per l’utente sul server di origine. Non aggiungere un header Authorization per l’origine come sostituto della risposta a una richiesta del proxy. Evita anche di inoltrare manualmente gli header delle credenziali del proxy a richieste estranee o di salvarli in header riutilizzati in tutta l’applicazione.

Se il proxy continua a restituire 407

• Verifica di usare l’host e la porta del proxy previsti.
• Controlla gli schemi annunciati dal proxy invece di presumere che usi Basic.
• Verifica lo stato dell’account e l’eventuale formato specifico del nome utente richiesto dal servizio.
• Controlla come vengono passati i caratteri speciali se le credenziali sono incorporate in un URL.
• Determina se l’autenticazione aziendale integrata nel browser richiede supporto del runtime o della piattaforma.
• Se le informazioni del client non bastano, chiedi all’amministratore un identificativo della richiesta o una voce del log del server ripuliti dai dati sensibili.

Un 403 o un CONNECT negato può dipendere dalla politica di accesso anche dopo un’autenticazione riuscita. Altri tentativi di password non concederanno accesso a una destinazione vietata.

L’HTTPS di destinazione non protegge ogni scambio di credenziali del proxy

L’autenticazione del proxy può avvenire prima che il TLS di destinazione sia stabilito. Se la connessione al proxy è in chiaro e il metodo espone credenziali riutilizzabili su quel collegamento, una destinazione HTTPS non protegge retroattivamente lo scambio. Scegli un trasporto e un’autenticazione adatti al servizio, e non inviare account privati a un proxy pubblico sconosciuto.

Rileggi i log dettagliati prima di condividerli. Anche quando uno strumento maschera i campi comuni delle credenziali, possono rimanere nomi utente, endpoint interni, cookie o altri dati identificativi.