عیبیابی ورود به پراکسی NTLM در curl
اگر پراکسی NTLM ورود را رد میکند، پشتیبانی نسخهٔ ساختهشدهٔ curl، چالش احراز هویت پراکسی و پیوستگی اتصال را بررسی کنید.
احراز هویت پراکسی NTLM شامل دستدهی است، نه فقط یک بار افزودن نام کاربری. پیش از تغییر گذرواژهٔ حساب، مطمئن شوید که پراکسی واقعاً NTLM ارائه میدهد و فایل اجرایی curl از آن پشتیبانی میکند.
curl --version
فهرست قابلیتهای همان فایل اجرایی را بررسی کنید که درخواست شما را اجرا میکند. نصب دیگر curl، تصویر کانتینر یا ساخت سیستمعامل ممکن است پشتیبانی متفاوتی از احراز هویت داشته باشد.
روش مخصوص پراکسی را انتخاب کنید
curl --proxy http://proxy.example:3128 --proxy-ntlm --proxy-user 'EXAMPLE\alice' --noproxy '' --connect-timeout 5 --max-time 20 https://example.com/
نقطهٔ پایانی، دامنه و نام کاربری نمونهاند. از قالبی که مدیر داده است استفاده کنید. اگر آرگومان گذرواژه نداشته باشد، curl میتواند آن را بپرسد، بهجای اینکه راز در فرمان نمایشدادهشده بماند.
چالش اولیهٔ احراز هویت میتواند بخشی از مذاکره باشد. آن را از رد شدن پس از دستدهی کامل متمایز کنید. برای پاسخ به چالش پراکسی از گزینهٔ NTLM مربوط به سرور مبدأ استفاده نکنید.
رفتار اتصال را در عیبیابی لحاظ کنید
وضعیت NTLM به اتصال وابسته است. دستدهی باید در مسیر اتصال مورد انتظار پیش برود؛ جایگزینی مکرر اتصالها بین مراحل آن میتواند مانع تکمیل شود.
در برنامهای که از libcurl استفاده میکند، مدیریت احراز هویت و استفادهٔ مجدد از اتصالها را به کتابخانه بسپارید. استخری عمومی نسازید که اتصالهای احراز هویتشده برای هویتهای متفاوت را قابل جایگزینی بداند. در سرویس چندپرشی یا واسط، بررسی کنید آیا آرایش اتصال لازم را حفظ میکند.
اگر پشتیبانی و انتخاب روش درستاند، قالب حساب، خطمشی دامنه و گزارشهای احراز هویت سرور را که دادههای حساسشان حذف شده بررسی کنید. پایان مهلت پیش از هر چالشی هنوز مشکل دسترسپذیری است، نه مدرک نادرست بودن گذرواژهٔ NTLM.
ردیابیهای مفصل ممکن است توکنهای احراز هویت و نامهای داخلی داشته باشند. آنها را محلی استفاده کنید و پیش از اشتراکگذاری دادههای حساس را حذف کنید؛ گزارش عمومی خطا به تبادل خام توکن نیاز ندارد.