احراز هویت پراکسی Basic و Digest
روشی برای احراز هویت پراکسی انتخاب کنید که هر دو طرف پشتیبانی کنند و چالش Digest را از انتقال رمزنگاری‌شده جدا بدانید.
پیش از تحمیل Basic یا Digest، پراکسی را در Proxy-Authenticate چالش بخوانید. کلاینت باید روشی را که سرویس ارائه می‌کند پشتیبانی کند؛ انتخاب Digest آن را به پراکسیِ فقط Basic اضافه نمی‌کند.
برای نقطهٔ پایانی که Digest را پشتیبانی می‌کند، curl می‌تواند از این استفاده کند:
curl --proxy http://proxy.example:3128 --proxy-digest --proxy-user alice --connect-timeout 5 --max-time 15 https://example.com/از نقطهٔ پایانی و حساب واقعی استفاده کنید. نام کاربری بدون گذرواژه به curl اجازه می‌دهد آن را درخواست کند. برای Basic، --proxy-basic را انتخاب کنید؛ احراز هویت سرور مبدأ گزینه‌های دیگری دارد. علاوه بر چالش، پشتیبانی ساخت curl که واقعاً اجرا می‌شود را بررسی کنید.
| روش | تبادل اعتبارنامه | حفاظتی که باید ارزیابی شود |
|---|---|---|
| Basic | یک جفت رمزگذاری‌شدهٔ نام کاربری و گذرواژه. | کدگذاری رمزنگاری نیست. |
| Digest | پاسخی مشتق‌شده از چالش. | الگوریتم‌ها، پارامترهای چالش و پیاده‌سازی کلاینت سطح حفاظت را تعیین می‌کنند؛ خود روش محتوای درخواست و پاسخ را رمزنگاری نمی‌کند. |
هر دو روش همچنان به انتقال مناسب بین کلاینت و پراکسی نیاز دارند. HTTPS مقصد خیلی دیر شروع می‌شود و نمی‌تواند ورود قبلی به پراکسی با متن آشکار را محافظت کند.
در سرور، کمک‌کننده‌های Digest ممکن است مواد اعتبارنامهٔ مخصوص realm و قالب خود را بخواهند. فایل NCSA مربوط به Basic خودکار backend مربوط به Digest نمی‌شود. قالب مستند کمک‌کنندهٔ انتخاب‌شده را به کار ببرید و سپس اعتبارنامه‌های غایب، نادرست و یک درخواست مجاز را بررسی کنید، در حالی که محدودیت‌های مبدأ و مقصد حفظ می‌شوند.