Налады проксі для 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 датычыцца сеткавага аўтэнтыфікатара, які тут выкарыстоўваецца.

Падобныя артыкулы