وقتی فراخوانی 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 به احرازکننده شبکه‌محوری مربوط است که اینجا استفاده می‌شود.

مقالات مرتبط