Watson Node SDK-ის პროქსის პარამეტრები API და IAM მოთხოვნებისთვის
გააზიარეთ გვირაბის აგენტი Watson-ის სერვისის კლიენტსა და მის IAM ავთენტიფიკატორს შორის, რათა ტოკენის მიღებამ პროქსი გამოიყენოს.
როცა Watson-ის გამოძახება სერვისამდე მისვლამდე ვერ ხერხდება, შეამოწმეთ, ხომ არ არის წარუმატებელი მოთხოვნა IAM ტოკენის მოთხოვნა. IAM-ით ავთენტიფიცირებული გამოძახება ჯერ IAM-ს, შემდეგ კი სერვისს დაუკავშირდება.
აპლიკაციაში, რომელიც უკვე იყენებს შესაბამის Watson SDK-ს და tunnel დამოკიდებულებას, ორივე ობიექტს ერთი და იგივე ქსელური პარამეტრები მიეცით:
const tunnel = require('tunnel');
const AssistantV2 = require('ibm-watson/assistant/v2');
const { IamAuthenticator } = require('ibm-watson/auth');
const httpsAgent = tunnel.httpsOverHttp({
proxy: { host: 'proxy.example', port: 8080 },
});
const network = { httpsAgent, proxy: false };
const authenticator = new IamAuthenticator({
apikey: apiKey,
...network,
});
const assistant = new AssistantV2({
version: serviceVersion,
serviceUrl,
authenticator,
...network,
});შეინარჩუნეთ აპლიკაციის არსებული apiKey, serviceVersion და serviceUrl. API-ისა და IAM-ის ბოლო წერტილები რჩება თავიანთ დანიშნულ დესტინაციებად; პროქსის მსმენელი აგენტშია. HTTP პროქსების სია შეიძლება მოგცეთ კანდიდატი მისამართები, როცა სერვისის ორივე საჯარო ბოლო წერტილზე წვდომა თქვენ მიერ არჩეული პროქსით შესაძლებელია.
tunnel.httpsOverHttp ამყარებს HTTPS გზას HTTP პროქსის გავლით. proxy: false ხელს უშლის SDK-ს, რომ ამ მორგებულ აგენტზე კიდევ ერთი ჩაშენებული პროქსის კონფიგურაცია გამოიყენოს.
თუ ადრე ეს პარამეტრები მხოლოდ assistant-ს გადასცემდით, ავთენტიფიკატორია ის გამოტოვებული ადგილი, რომელიც უნდა შემოწმდეს. საბაზისო ავთენტიფიკაციასა და უკვე გაცემულ bearer ტოკენს ტოკენის მიღების განსხვავებული სასიცოცხლო ციკლი აქვთ, ამიტომ ეს დამატებითი IAM გზა აქ გამოყენებულ ქსელზე დაფუძნებულ ავთენტიფიკატორს ეხება.