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-ის ქსელური და წვდომის პოლიტიკები მაინც წყვეტს, შეუძლია თუ არა აპლიკაციას საიდუმლოს წაკითხვა.

დაკავშირებული სტატიები