Azure Key Vault .NET: פּראָקסי איינשטעלונגען פֿאַר סודות און טאָקען בקשות
באַשטימט דעם זעלבן Azure Core טראַנספּאָרט צו SecretClientOptions און ClientSecretCredentialOptions איידער איר אָנהייבט אַן פֿון די צוויי בקשה וועגן.
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
});ניצט די עכטע vaultUrl, tenantId, clientId און clientSecret פֿון דער אַפּלאַקיישאַן. די צוויי Transport = transport צוטיילונגען זענען מיט כּוונה: איין פֿירט דעם טאָקען באַקומען און די אַנדערע די Key Vault סוד בקשות.
האַלט vaultUrl ווי דער עכטער סוף־פּונקט פֿון דער קאַסע. דער WebProxy פֿון דעם באַהאַנדלער האַלט דעם מיטלמאַן; עפֿנטלעכע HTTP קאַנדידאַטן זענען פֿאַראַן אין דער HTTP פּראָקסי ליסטע ווען די נעץ פּאָליטיק פֿון דער קאַסע ערלויבט דעם וועג; קאָנפֿיגורירט איר Credentials איידער די קליענטן ווערן געבויט אויב די נעץ פֿאָדערט עס.
ניצט ווידער דעם טראַנספּאָרט פֿאַר דער אַרבעט פֿון די קליענטן און באַפֿרייט אייגענע רעסורסן ביים אָפּשאַלטן. אַ געראָטן פּראָקסי פֿאַרבינדונג שטעלט אַ וועג אויף, אָבער די נעץ און צוטריט פּאָליטיקעס פֿון Key Vault באַשטימען נאָך אַלץ צי די אַפּלאַקיישאַן מעג לייענען דעם סוד.