ສຳລັບ 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 ຂອງ handler ຖືກກຳນົດຊັດເຈນ DefaultProxyCredentials ບໍ່ແທນ WebProxy.Credentials.

UseDefaultCredentials ກໍມີຂອບເຂດຕາມອັອບເຈັກ: ການຢັ້ງຢືນເຊີບເວີຂອງ handler ກັບການຢັ້ງຢືນພຣັອກຊີຂອງ WebProxy ຕ່າງກັນ. ສົ່ງບັນຊີຜູ້ໃຊ້ຂະບວນການບໍ່ແມ່ນຄຳຕອບທົ່ວໄປຕໍ່ 407.

ຖ້າຄຳຮ້ອງຂໍຢັ້ງຢືນຍັງມີ ໃຫ້ກວດວິທີຈິງ, ຈຸດປາຍທີ່ເລືອກ ແລະ ອິນສະແຕນ client/handler. ການຢັ້ງຢືນພຣັອກຊີອາດເກີດກ່ອນ TLS ປາຍທາງ ດັ່ງນັ້ນຫົວຂໍ້ Authorization ຂອງເວັບໄຊຕອບມັນບໍ່ໄດ້. ການຮອງຮັບຍັງຂຶ້ນກັບ handler, ແພລດຟອມ, ບໍລິການ ແລະ ນະໂຍບາຍນຳໃຊ້; ບໍ່ຕ້ອງປ່ຽນ Windows ພຣັອກຊີທົ່ວລະບົບ.

ບົດຄວາມທີ່ກ່ຽວຂ້ອງ