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 עדיין מחליטה אם היישום רשאי לקרוא את הסוד.