Proxy-ynstellingen fan 'e Watson Node SDK foar API- en IAM-fersiken
Diel de tunnelagent tusken de Watson-tsjinstklient en syn IAM-autentisearrer, sadat it heljen fan tokens de proxy brûke kin.
As in Watson-oprop mislearret foardat it de tsjinst berikt, kontrolearje dan of it mislearre fersyk it IAM-tokenfersyk is. In fersyk dat mei IAM autentisearre is, kin earst IAM en dêrnei de tsjinst benei komme.
Yn in applikaasje dy't al de oanbelangjende Watson SDK en de ôfhinklikens tunnel brûkt, jou beide objekten deselde netwurkynstellingen:
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,
});Hâld de besteande apiKey, serviceVersion en serviceUrl fan 'e applikaasje. De API- en IAM-einpunten bliuwe har bedoelde bestimmingen; de proxy-ôfharker heart by de agent. De HTTP-proxylist kin kandidaatadressen leverje as beide iepenbiere tsjinst-einpunten te berikken binne fia in proxy dy't jo kieze.
tunnel.httpsOverHttp leit it HTTPS-paad oan fia de HTTP-proxy. proxy: false foarkomt dat de SDK noch in ynboude proxykonfiguraasje oer dy oanpaste agent hinne set.
As jo dizze ynstellingen earder allinnich oan assistant joegen, dan is de autentisearrer it ûntbrekkende plak om te kontrolearjen. Basisautentikaasje en in al útjûn bearer-token hawwe ferskillende libbenssyklussen foar it heljen fan tokens, dus dit ekstra IAM-paad jildt foar de netwurkbasearre autentisearrer dy't hjir brûkt wurdt.