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 は HTTP プロキシ経由の HTTPS 経路を確立します。proxy: false は、そのカスタムエージェントの上に SDK が別の組み込みプロキシ設定を重ねて適用するのを防ぎます。

以前にこの設定を assistant にだけ渡していた場合、認証子こそ確認すべき抜け落ちた箇所です。基本認証と発行済みの bearer トークンではトークン取得のライフサイクルが異なるため、この追加の IAM 経路はここで使っているネットワークベースの認証子に当てはまります。

関連記事