Пресретање у Squid-у наспрам експлицитне аутентикације прокија
Објасните зашто се обична експлицитна аутентикација прокија не може једноставно додати слушаоцу пресретања у Squid-у.
Клијент експлицитног прокија зна да разговара с прокијем. Пресретнути прегледач мисли да се повезао са сајтом. Та разлика је кључна за аутентикацију.
Уобичајена аутентикација прокија користи изазов прокија и одговор ауторизације прокија. Клијент који није изабрао проки не би требало олако да шаље акредитиве прокија неочекиваном посреднику.
Зато Squid-ове смернице за пресретање не подржавају једноставно спајање proxy_auth са режимом пресретања. Исправан помоћник за Basic аутентикацију не мења шта прегледач сматра удаљеном крајњом тачком.
Ако идентификованим корисницима треба уобичајен аутентификован проследни проки, подесите клијенте експлицитно, директно или преко одговарајуће управљане конфигурације прокија. Држите тај слушалац и његову политику аутентикације одвојено од слушаоца пресретања.
Портал за аутентикацију, систем идентитета на нивоу мреже или TLS пресретање други су дизајн са другачијим захтевима за поверење и распоређивање. То није поправка у једном реду за недостајућу размену експлицитног прокија.
Не решавајте недостатак упита тако што ћете пресретнуту услугу учинити јавном или дозволити сваки клијент. Прво одлучите да ли је захтев експлицитна аутентикација корисника или пресретање саобраћаја који никада није био конфигурисан за проки. Оба траже различите претпоставке.