HTTP 407 mi 401 mi: hangi giriş başarısız oluyor?
Proxy kimlik doğrulamasını site kimlik doğrulamasından ayırın, doğru başlıkları inceleyin ve bilgileri yanlış tarafa göndermeyin.
407, proxy’de kimlik doğrulamanızı ister. 401, hedef kaynak için kimlik doğrulaması ister. Bir istek ikisiyle de karşılaşabilir; parola vermeden önce kimin istediğini belirleyin.
Durumu ve kimlik doğrulama çağrısı başlıklarını karşılaştırın
| Yanıt | Kimlik doğrulama çağrısı başlığı | Kimlik bilgisi başlığı | İlgili taraf |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | Aracı bir proxy |
| 401 Unauthorized | WWW-Authenticate | Authorization | Kaynak sunucudaki içeriğin kimlik doğrulama akışı |
Durum kodu önemli ilk ipucudur, ancak tüm alışverişi inceleyin. Metninde 407 gösteren bir sayfa, gerçek bir HTTP 407 yanıtı değildir. Benzer şekilde özel bir web giriş sayfası 200 döndürüp uygulama katmanında hâlâ kimlik doğrulama isteyebilir.
HTTPS neden siteye ulaşmadan 407 ile başarısız olabilir?
Sıradan bir HTTP proxy üzerinden HTTPS isteği gönderildiğinde istemci genellikle önce CONNECT tüneli kurulmasını ister. Proxy, bu CONNECT isteği için kimlik doğrulaması talep edebilir. Doğrulama tamamlanmadıysa hedefin TLS oturumu henüz tünel üzerinden kurulmamıştır; dolayısıyla site API belirtecini değiştirmek bu aşamayı muhtemelen düzeltmez.
Çağrının nerede göründüğünü ayrıntılı istek çıktısıyla inceleyin:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/Yerel dinleyiciyi kendinizinkiyle değiştirip günlükteki ilk kimlik doğrulama çağrısını okuyun. CONNECT sırasında 407, hedef TLS’den öncedir; başarılı bir tünelden sonra ise 401 gelebilir.
Proxy bilgilerini proxy arayüzüyle sağlayın
Güvendiğiniz bir yöneticinin verdiği uç nokta ve hesap için curl, proxy doğrulama yöntemini anlaşarak belirleyebilir ve eksik parolayı sorabilir:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/Örnek uç nokta ve kullanıcıyı yetkili olduğunuz hizmetin bilgileriyle değiştirin. Yalnızca kullanıcı adı vermek parolanın yukarıdaki komuta doğrudan yazılmasını önler. Yöntem desteği curl derlemesine ve proxy’ye göre değişebilir; anlaşma başarısızsa gerçek çağrıyı ve derlemenin özelliklerini kontrol edin.
Proxy doğrulama seçeneği, curl’ün kaynak sunucu kullanıcısını doğrulayan seçeneğinden ayrıdır. Proxy çağrısının yerine kaynak sunucuya ait Authorization başlığı eklemeyin. Proxy kimlik bilgisi başlıklarını ilgisiz isteklere elle iletmeyin veya uygulama genelinde yeniden kullanılan başlıklarda saklamayın.
Proxy sürekli 407 döndürüyorsa
- Amaçlanan proxy ana makinesini ve portunu kullandığınızı doğrulayın.
- Basic varsaymak yerine proxy’nin bildirdiği doğrulama yöntemlerini inceleyin.
- Hesap durumunu ve hizmetin özel kullanıcı adı biçimi isteyip istemediğini doğrulayın.
- Bilgiler URL içindeyse özel karakterlerin nasıl aktarıldığını kontrol edin.
- Tarayıcıya entegre kurumsal kimlik doğrulamanın çalışma zamanı veya platform desteğine ihtiyaç duyup duymadığını belirleyin.
- İstemci kanıtları yetersizse yöneticiden hassas verileri temizlenmiş istek kimliği veya sunucu günlük kaydı isteyin.
403 veya reddedilen CONNECT, başarılı girişten sonra bile erişim politikası kararı olabilir. Daha fazla parola denemesi yasak bir hedefe erişim sağlamaz.
Hedefin HTTPS kullanması her proxy kimlik bilgisi alışverişini korumaz
Proxy kimlik doğrulaması hedef TLS kurulmadan gerçekleşebilir. Proxy’nin kendisine bağlantı şifresizse ve yöntem o bağlantıda yeniden kullanılabilir bilgileri açığa çıkarıyorsa, HTTPS hedefi geçmişteki bu alışverişi sonradan korumaz. Hizmete uygun taşıma ve doğrulama düzenini seçin; özel hesapları bilinmeyen genel proxy’ye göndermeyin.
Ayrıntılı günlükleri paylaşmadan önce inceleyin. Araç yaygın kimlik bilgisi alanlarını maskelese de kullanıcı adları, iç uç nokta adları, çerezler veya başka tanımlayıcı bilgiler kalabilir.