Mag-instellinge vir die Watson Node-SDK vir API- en IAM-versoeke

Deel die tonnel-agent tussen die Watson-dienskliënt en sy IAM-verifikator sodat tokenverkryging die mag kan gebruik.

Wanneer 'n Watson-oproep misluk voordat dit die diens bereik, kontroleer of die mislukte versoek die IAM-tokenversoek is. 'n Oproep met IAM-verifikasie kan eers IAM kontak en daarna die diens.

In 'n toepassing wat reeds die betrokke Watson-SDK en die tunnel-afhanklikheid gebruik, gee dieselfde netwerkinstellings aan albei objekte:

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,
});

Behou die toepassing se bestaande apiKey, serviceVersion en serviceUrl. Die API- en IAM-eindpunt bly hul bedoelde bestemmings; die mag-luisteraar hoort in die agent. Die HTTP-maglys kan kandidaatadresse verskaf wanneer albei openbare diens-eindpunte deur 'n mag van jou keuse bereik kan word.

tunnel.httpsOverHttp vestig die HTTPS-pad deur die HTTP-mag. proxy: false verhoed dat die SDK nog 'n ingeboude magkonfigurasie bo-op daardie pasgemaakte agent toepas.

As jy hierdie instellings voorheen net aan assistant gegee het, is die verifikator die ontbrekende plek om te ondersoek. Basiese verifikasie en 'n reeds uitgereikte bearer-token het verskillende lewensiklusse vir tokenverkryging, so hierdie bykomende IAM-pad geld vir die netwerkgebaseerde verifikator wat hier gebruik word.

Verwante artikels