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.

Подобни статии