Når et Watson-kall feiler før det når tjenesten, sjekk om den mislykkede forespørselen er IAM-tokenforespørselen. Et IAM-autentisert kall kan kontakte IAM først og tjenesten etterpå.

I et program som allerede bruker den aktuelle Watson SDK-en og tunnel-avhengigheten, gi de samme nettverksinnstillingene til begge objektene:

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

Behold programmets eksisterende apiKey, serviceVersion og serviceUrl. API- og IAM-endepunktet forblir de tiltenkte destinasjonene; proxy-lytteren hører til agenten. listen over HTTP-proxyer kan gi kandidatadresser når begge de offentlige tjenesteendepunktene kan nås gjennom en proxy du velger.

tunnel.httpsOverHttp etablerer HTTPS-banen gjennom HTTP-proxyen. proxy: false hindrer SDK-en i å legge på en annen innebygd proxykonfigurasjon oppå den egendefinerte agenten.

Hvis du tidligere bare ga disse innstillingene til assistant, er autentisatoren stedet som mangler og bør sjekkes. Grunnleggende autentisering og et allerede utstedt bæretoken har ulike livssykluser for tokenhenting, så denne ekstra IAM-banen gjelder for den nettverksbaserte autentisatoren som brukes her.

Relaterte artikler