Testing av proxy-legitimasjon: førespurnadssuksess kontra fersk validering
Bruk ein kontrollert destinasjon, og skil deretter ein tillaten førespurnad frå fersk verifisering av det oppgjevne proxy-passordet.
Ein førespurnad som lukkast gjennom ein proxy, provar at den operasjonen var tillaten. Han provar kanskje ikkje at passordet vart kontrollert på nytt: destinasjonen kan vere unnteken, eller tilkoplinga kan alt vere autentisert.
For ein operasjonskontroll nyttar du endepunktet du kontrollerer, med eit kjent lite svar og ein tilgangspolicy kontoen skal oppfylle:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user 'USER:PROXY_PASSWORD' https://probe.example/statusEndepunktet og kontoen er plasshaldarar. Dette er mellomliggjande legitimasjon, skild frå kvar innlogging på destinasjonen.
Hald svarstadiet og utfordringa saman. Ein 407 kan starte eller halde fram forhandling, rapportere metodar som ikkje er støtta eller avvise ein konto. Ein 403 kan syne ei policyavvising, og ein seinare nettstadsfeil kan kome etter ei vellukka proxy-innlogging.
For fersk kontovalidering nyttar du den støtta kontokontrollen til operatøren eller loggar over autentisert identitet. På din eigen proxy kan backend-prov skilje faktisk validering frå ein anonymt tillaten førespurnad. Ved passordendringar tek du med valideringsvindauget i hurtiglageret når du avgjer om den gamle legitimasjonen burde ha slutta å verke. For Squid 6.13 Basic styrer credentialsttl eit valideringsvindauge i hurtiglageret.