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 இன் நெட்வொர்க் மற்றும் அணுகல் கொள்கைகள் இன்னும் தீர்மானிக்கின்றன.

தொடர்புடைய கட்டுரைகள்