یک صفحه پایش باید بدون ورود به پروکسی کار کند. قاعده واضح http_access allow status_site است. اگر پیش از احراز هویت قرار گیرد، می‌تواند این استثنا را به مشتریانی هم بدهد که هرگز قصد سرویس‌دهی به آن‌ها را نداشتید.

برای Squid 6 یا 7، شرایط استثنا را کنار هم نگه دارید. پس از محافظت‌های موجود مدیریت، پورت ناامن، CONNECT و سرویس محلی، بخش مربوط می‌تواند چنین باشد:

acl office_clients src 192.0.2.0/24
acl status_site dstdomain status.example.net
acl signed_in proxy_auth REQUIRED

http_access allow office_clients status_site
http_access allow office_clients signed_in
http_access deny all

شبکه و نام میزبان جای‌نگهدار هستند. احراز هویت همچنان به پیکربندی کمکی موجود خود نیاز دارد. این بخش استثنای یک سیاست دسترسی است، نه پیکربندی کامل پروکسی.

خط اول به مشتریان انتخاب‌شده اجازه می‌دهد بدون ارزیابی ACL ورود به آن مقصد برسند. خط بعدی به همان مشتریان جای دیگر را فقط پس از احراز هویت اجازه می‌دهد. اجازه‌های گسترده پیشین یا مسیرهای جایگزین بعدی می‌توانند نتیجه را تغییر دهند، بنابراین سیاست مرتب کامل، از جمله فایل‌های واردشده، را بخوانید.

استثنا را فقط برای پرهیز از یک اعلان بالای محافظت‌های پورت مقصد منتقل نکنید. یک سایت مجاز روی پورت ناخواسته هنوز مسیری متفاوت است. همچنین تصمیم بگیرید آیا میزبان دقیق یا زیردامنه‌های آن باید واجد شرایط باشند، به‌جای افزودن پسوندی بی‌جهت گسترده.

استثنای نام میزبان مقصد منطبق را پوشش می‌دهد، نه هر وابستگی‌ای که صفحه‌اش بارگذاری می‌کند. تغییرمسیرها و دارایی‌های شخص ثالث می‌توانند به‌طور مشروع با الزام عادی ورود روبه‌رو شوند.

برای HTTP ساده، پروکسی می‌تواند در صورت مناسب بودن از اطلاعات URL دقیق‌تر استفاده کند. یک درخواست معمولی HTTPS CONNECT مسیر صفحه را آشکار نمی‌کند، پس قاعده «فقط یک صفحه» را نمی‌توان از استثنای تونل برای کل میزبان استنتاج کرد.

مقالات مرتبط