IBM i QSYS2.HTTP_GET: تكوين وكيل أمامي

استخدم خيارات JSON الموثقة للوكيل في IBM i وميز حدود ما تقوله عن مصادقة NTLM.

يأخذ QSYS2.HTTP_GET عنوان الوجهة ثم مستند خيارات JSON. ويستخدم عنوان الوكيل host,port لا عنوان URL للوكيل. لوكيل HTTP عادي بلا مصادقة قد تبدو الخيارات هكذا:

VALUES QSYS2.HTTP_GET(
  'https://api.example.net/status',
  '{"proxy":"proxy.example.net,8080",
    "proxySsl":"false",
    "headers":{"Accept":"application/json"}}'
);

يصف proxySsl الاتصال بالوكيل. توثق IBM القيمة الافتراضية true، لذا عطلها صراحة عندما يتوقع المستمع HTTP عاديا. تبقى الوجهة على HTTPS. لاختبار مسموح يمكن لعنوان من قائمة وكلاء HTTP أن يملأ المضيف والمنفذ بصيغة القيمة المفصولة بفواصل.

للمصادقة حد منفصل. وثق proxyAuth بصيغة userid,password ولا يسمح به إلا عندما يكون proxySsl بقيمة true. ويوفر basicAuth بيانات اعتماد خدمة الوجهة. ولا يغني ترويسة الأصل عن مصادقة الوكيل.

تقديم اسم مستخدم وكلمة مرور لا يختار NTLM بحد ذاته. لا توفر خيارات SQL المنشورة محدد آلية NTLM. إذا طلب الوكيل NTLM فتحقق من دعم ذلك لإصدار IBM i ومستوى الصيانة المثبتين.

ميز أيضا عائلتي IBM SQL HTTP. تستخدم دوال QSYS2 تقنية ILE، ويستخدم SYSTOOLS الأقدم جافا. وتثبيت Authenticator في جافا لمسار SYSTOOLS ليس إعدادا لنقل QSYS2 الأصلي.

طابق توفر الخيارات، بما فيها الشكل الكائني لـheaders، مع توثيق الإصدار ومستوى PTF المثبتين. وإذا احتجت نقلا آخر لمخطط مصادقة الوكيل فاختر ما يوثق ذلك المخطط صراحة.

مقالات ذات صلة