یک سرویس ICAP می‌تواند هویت احراز هویت‌شده‌ای را که Squid می‌شناسد دریافت کند، اما هر دو طرف باید درباره نحوه انتقال این هویت توافق کنند. فقط نام‌گذاری یک سرآیند، ارسال نام کاربری را فعال نمی‌کند.

برای یک پیکربندی موجود Squid 7 با پشتیبانی ICAP و احراز هویت کلاینت، تنظیمات مرتبط می‌توانند این‌ها باشند:

adaptation_send_username on
icap_client_username_header X-Authenticated-User
icap_client_username_encode off

این مورد سرویس ICAP موجود، قواعد انطباق و پیکربندی دسترسی پروکسی را تکمیل می‌کند. نه احراز هویت ایجاد می‌کند و نه سرویس انطباق.

با ورودی سرویس هماهنگ شوید

سرآیند پیش‌فرض نام کاربری Squid برابر X-Client-Username است. اگر آداپتور X-Authenticated-User را انتظار دارد، نام پیکربندی‌شده Squid را مانند بالا تغییر دهید یا آداپتور را برای خواندن مقدار پیش‌فرض پیکربندی کنید. تطبیق نام سرآیند از قواعد HTTP بدون حساسیت به حروف بزرگ و کوچک پیروی می‌کند.

رمزگذاری نیز باید هماهنگ باشد. وقتی icap_client_username_encode فعال است، Squid مقدار را با Base64 رمزگذاری می‌کند. سرویس باید این نمایش را رمزگشایی کند، نه اینکه آن را نام کاربری دیگری تلقی کند.

این فراداده مربوط به تبادل ICAP میان Squid و سرویس آن است. دستوری برای ارسال سرآیند هویت کاربر به هر وب‌سایت مقصد نیست.

اگر سرویس هنوز نشانی IP گزارش می‌کند

تأیید کنید که تراکنش واقعاً یک نام کاربری احراز هویت‌شده در Squid دارد، ارسال نام کاربری فعال است و سرویس سرآیند پیکربندی‌شده را می‌خواند. بازگشت آداپتور به نشانی کلاینت ثابت نمی‌کند که احراز هویت Squid شکست خورده است؛ ممکن است خود تحویل نباشد یا نام نادرستی داشته باشد.

این هویت را فقط در مسیر کنترل‌شده میان Squid و آداپتور قابل اعتماد بدانید. این دستورالعمل‌ها وابسته به نسخه‌اند: مرجع پیکربندی آن‌ها را برای Squid 7 و شاخه‌های پیشین فهرست می‌کند و در Squid 8 در دسترس نبودنشان را نشان می‌دهد.

مقالات مرتبط