کون سی .NET اسناد پراکسی کے لیے ہیں؟

HTTP پراکسی کی تصدیق میں WebProxy.Credentials، منزل کے سرور کی اسناد اور DefaultProxyCredentials کا فرق سمجھیں۔

حسب ضرورت WebProxy کے لیے پراکسی اکاؤنٹ اسی آبجیکٹ پر رکھیں۔ دوسری .NET اسناد کی خصوصیات کے وصول کنندہ الگ ہیں:

خصوصیتوصول کنندہ
WebProxy.Credentialsاس آبجیکٹ کی نمائندہ پراکسی۔
HttpClientHandler.Credentialsمنزل کا سرور۔
DefaultProxyCredentialsسسٹم کی طے شدہ پراکسی جب Proxy، null اور UseProxy، true ہو۔

یہ .NET 10 مثال واضح طور پر مقرر پراکسی اور اس کا اپنا اکاؤنٹ دیتی ہے:

using System;
using System.Net;
using System.Net.Http;

string password = Environment.GetEnvironmentVariable("PROXY_PASSWORD")
    ?? throw new InvalidOperationException("Set PROXY_PASSWORD");

var proxy = new WebProxy("http://203.0.113.10:8080")
{
    Credentials = new NetworkCredential("proxy-user", password)
};

using var handler = new HttpClientHandler
{
    Proxy = proxy,
    UseProxy = true
};
using var client = new HttpClient(handler)
{
    Timeout = TimeSpan.FromSeconds(15)
};

using var response = await client.GetAsync("https://example.com/");
Console.WriteLine((int)response.StatusCode);

دستاویزی اینڈ پوائنٹ بدلیں اور آپریٹر کا دیا اکاؤنٹ استعمال کریں۔ بغیر تصدیق فہرست اندراج کے لیے فرضی لاگ ان نہ بنائیں۔ چونکہ ہینڈلر کی Proxy واضح طور پر مقرر ہے، DefaultProxyCredentials، WebProxy.Credentials کا بدل نہیں۔

UseDefaultCredentials کی حد بھی آبجیکٹ کے مطابق ہے؛ ہینڈلر کی سرور تصدیق اور WebProxy کی پراکسی تصدیق الگ ہیں۔ عمل کے صارف کا اکاؤنٹ بھیجنا 407 کا عمومی جواب نہیں۔

تصدیق کا مطالبہ باقی رہے تو اصل اسکیم، منتخب اینڈ پوائنٹ اور کلائنٹ/ہینڈلر کی مثال دیکھیں۔ پراکسی تصدیق منزل کے TLS سے پہلے ہو سکتی ہے، اس لیے سائٹ کا Authorization ہیڈر اسے جواب نہیں دے سکتا۔ حمایت اب بھی ہینڈلر، پلیٹ فارم، سروس اور تعیناتی کی پالیسی پر منحصر ہے؛ عالمی Windows پراکسی تبدیلی ضروری نہیں۔

متعلقہ مضامین