შეინახეთ პროქსის საშუალებით კონფიგურირებული GoogleCredential-ის ასლი .NET-ში

კონფიგურირეთ ტოკენის HTTP სამუშაო მიღებამდე და გადასცეთ routedCredential შემდგომ; საწყისი credential ინარჩუნებს ადრინდელ კონფიგურაციას.

var proxy = new System.Net.WebProxy("http://proxy.example:8080")
{
    Credentials = proxyCredentials
};
var factory = Google.Apis.Http.HttpClientFactory.ForProxy(proxy);
var routedCredential = credential.CreateWithHttpClientFactory(factory);

credential აპლიკაციის არსებული GoogleCredential-ია. მეთოდი აბრუნებს ასლს, ამიტომ ტოკენის სამუშაოსა ან API აუთენტიფიკაციისთვის გამოიყენეთ routedCredential, ორიგინალით გაგრძელების ნაცვლად.

proxyCredentials შუამავალი ანგარიშის იდენტიფიკატორია; გამოტოვეთ ინიციალიზატორი, თუ არ არის საჭირო. ამ არაუთენტიფიცირებულ შემთხვევაში HTTP პროქსი სია შეიძლება მოგაწოდოთ endpoint-კანდიდატები, როცა ტოკენის დანიშნულება საჯაროა და საჯარო პროქსი მარშრუტი დაშვებულია. შეინარჩუნეთ Google credential-ის საჭირო ტიპი და scope-ები. პროქსის მონაცემები არ ცვლის კლიენტის საიდუმლოს, სერვისის ანგარიშის გასაღებს ან წვდომის ტოკენს.

API სერვისის კლიენტი მშენებლობის სხვა გზაა. მიეცით ამ ტრანსპორტსაც განზრახული factory, როცა სერვისისა და ტოკენის მოთხოვნებს პროქსი სჭირდება. მხოლოდ სერვისის კონფიგურაციამ შეიძლება ადრინდელი ტოკენის მოთხოვნა დაუკავშირებელი დატოვოს.

ქეშირებული წვდომის ტოკენი თავიდან ირიდებს ახალ გაცვლას. შეადარეთ რეალურად წარუმატებელი ჰოსტი და მოთხოვნა, ნაცვლად იმისა, რომ ქეშ-ტოკენის ოპერაცია ან ობიექტის აგება ახალ პროქსი კავშირად ჩათვალოთ.

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