Azure Key Vault .NET: Tetapan Proksi untuk Rahsia dan Permintaan Token
Berikan pengangkutan Azure Core yang sama kepada SecretClientOptions dan ClientSecretCredentialOptions sebelum memulakan mana-mana laluan permintaan.
var handler = new System.Net.Http.HttpClientHandler
{
UseProxy = true,
Proxy = new System.Net.WebProxy(
"http://proxy.example.net:8080")
};
var transport = new Azure.Core.Pipeline.HttpClientTransport(handler);
var credential = new Azure.Identity.ClientSecretCredential(
tenantId, clientId, clientSecret,
new Azure.Identity.ClientSecretCredentialOptions
{
Transport = transport
});
var vault = new Azure.Security.KeyVault.Secrets.SecretClient(
new Uri(vaultUrl),
credential,
new Azure.Security.KeyVault.Secrets.SecretClientOptions
{
Transport = transport
});Gunakan vaultUrl, tenantId, clientId dan clientSecret sebenar aplikasi. Dua penetapan Transport = transport memang disengajakan: satu menghalakan pemerolehan token dan satu lagi permintaan rahsia Key Vault.
Kekalkan vaultUrl sebagai titik akhir peti besi sebenar. WebProxy pengendali memegang perantara; calon HTTP awam tersedia dalam senarai proksi HTTP apabila dasar rangkaian peti besi membenarkan laluan itu; konfigurasikan Credentials-nya sebelum membina klien jika rangkaian memerlukannya.
Guna semula pengangkutan untuk beban kerja klien dan lepaskan sumber milik semasa mematikan. Sambungan proksi yang berjaya menetapkan laluan, tetapi dasar rangkaian dan akses Key Vault masih menentukan sama ada aplikasi boleh membaca rahsia itu.