Azure Key Vault .NET: prokseaj agordoj por sekretoj kaj petoj pri ĵetonoj
Atribuu la saman Azure Core-transportilon al SecretClientOptions kaj ClientSecretCredentialOptions antaŭ ol komenci ajnan el la du petvojoj.
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
});Uzu la verajn vaultUrl, tenantId, clientId kaj clientSecret de la aplikaĵo. La du atribuoj Transport = transport estas intencaj: unu enkursigas la akiron de ĵetono kaj la alia la petojn pri sekretoj de Key Vault.
Konservu vaultUrl kiel la realan finan punkton de la konservejo. La WebProxy de la traktilo tenas la peranton; publikaj HTTP-kandidatoj haveblas en la listo de HTTP-prokuriloj kiam la retpolitiko de la konservejo permesas tiun vojon; agordu ĝian Credentials antaŭ ol krei la klientojn se la reto postulas tion.
Reuzu la transportilon por la laborŝarĝo de la klientoj kaj liberigu posedatajn rimedojn ĉe malŝalto. Sukcesa proksea konekto starigas vojon, sed la ret- kaj alirpolitikoj de Key Vault ankoraŭ decidas ĉu la aplikaĵo rajtas legi la sekreton.