اختر مخطط المصادقة في إعداد الوكيل في httr
قدّم حساب الوكيل واختيارًا صريحًا لـBasic أو NTLM عبر دالة use_proxy في httr عندما يتلقى الطلب 407.
تأخذ دالة use_proxy في httr حساب الوكيل ومخطط المصادقة معًا. وفي نداء httr الأعلى مستوى يمكن تطبيق الإعداد نفسه حول تعبير محدَّد:
route <- httr::use_proxy(
'proxy.example',
port = 8080,
username = Sys.getenv('PROXY_USER'),
password = Sys.getenv('PROXY_PASSWORD'),
auth = 'ntlm'
)
response <- httr::GET('https://api.example/items', route)
لا تستخدم ntlm إلا عندما يقدّم الوكيل ذلك المخطط ويدعمه بناء libcurl المثبَّت. وإذا فشل التبادل رغم ذلك، فإن تشخيصات وكيل NTLM في curl تشرح التحدي وفحوص دعم البناء واستمرارية الاتصال. ولوكيل يتوقع Basic اختر auth = 'basic'. وBasic هو الافتراضي في use_proxy؛ ومجرد تقديم اسم مستخدم بنمط Windows لا يختار NTLM.
تُسند الدالة هذه القيم إلى خيارات proxyuserpwd وproxyport وproxyauth في libcurl. ويجب أن تكون وسيطة port رقمية.
يتعلق 407 بتسجيل دخول الوكيل. أما الحساب المقدَّم لواجهة API عبر httr::authenticate أو عبر ترويسة Authorization في التطبيق فله مستقبِل مختلف.
احتفظ بنقطة نهاية الوكيل الفعلية والتحدي المعلن مع تقرير الخطأ، دون الأسرار. فالحساب الخاطئ والمخطط الخاطئ وطريقة المصادقة غير المدعومة تحتاج إصلاحات مختلفة؛ وتغيير التحقق من الشهادة لا يختار بينها.