почему строка пользовательского агента Internet Explorer 9 («часть MSIE») не работает с прокси и / или NTLM-аутентификацией в Apache Tomcat 7?

912
Allende

В моей сети мы поддерживаем прокси (pac-скрипт), когда пытаемся получить доступ к сайту в следующем формате:

http://serverName.domain.com:8080/somePath

IE (9.0.8112.16421) не может просматривать сайт (для этого требуется http auth NTLM), но я могу открыть домашнюю страницу по адресу http://serverName.domain.com:8080/ (которая на самом деле является веб-сервером). домашняя страница Apache Tomcat)

Пожалуйста, смотрите последнее обновление, похоже, проблема больше связана с аутентификацией NTLM

Однако я заметил, что Chrome отлично просматривает сайт и, открыв инструменты разработчика (F12) в Internet Explorer и установив строку User Agent в значение «Chrome», IE сможет просматривать сайт без каких-либо других изменений.

Теперь вопрос, есть ли проблема с прокси + http auth + ie? << udpate: не был ли прокси >> что еще меняется при использовании строк Chrome User Agent, почему так работает?

Я читал и знаю, что есть несколько способов изменить пользовательский агент IE9 (9.0.8112.16421), например «навсегда», с помощью IEM ( http://technet.microsoft.com/en-us/library/cc770379.aspx ) и Windows регистрируется, но нужны права администратора и не знаю, в этом ли проблема или есть что-то еще.

Примечание. При проверке вкладки «Сеть» в Dev Tools (IE) результаты показывают «Прервано», и нет даже заголовков / тела запроса, только доступны заголовки ответа:

Key Value Response HTTP/1.1 401 Unauthorized Server Apache-Coyote/1.1 WWW-Authenticate NTLM TlRMTVNTUAACAAAAAAAAACgAAAABggAAAAICAgAAAAAAAAAAAAAAAA== Content-Type text/html;charset=utf-8 Content-Length 951 Date Fri, 16 Jan 2015 17:04:36 GMT Cache-Control proxy-revalidate Proxy-Connection Keep-Alive Connection Keep-Alive Proxy-support Session-based-authentication 

Обновление Я проверил с партнерами в другой стране, и они могут открывать сайт, не переключая их строку User Agent, прокси-скрипт выглядит примерно так же, информация о DNS из команды ipconfig выглядит одинаково, я могу только думать, что есть что-то в нашем прокси-сервере (где находится скрипт pac) << update: не был прокси >>

Я думаю, что могу отказаться от любого из DNS-серверов, поскольку, переключив User Agent, я могу попасть на сайт, но, пожалуйста, прокомментируйте, если знаете, что я не прав насчет этого.

Обновление 2 Просто понял, что при настройке ЛЮБОГО другого пользовательского агента пользователя я могу открыть сайт, я даже установил слово «привет» и работал. После нескольких попыток / неудач также выяснилось, что часть «MSIE» в строке User Agent является той, которая вызывает сбой (помимо любой другой неверной конфигурации в прокси-сервере).

Удалив "MSIE" или даже только один символ, я могу просматривать сайт, но если я включу эти 4 символа в ЛЮБУЮ другую строку User Agent, то я не смогу просмотреть сайт.

Обновление 3 Пока мои товарищи по команде в других странах могут получить доступ к сайту без использования другой строки агента пользователя, все указывает на то, что прокси + http аутентификация портится с аутентификацией активного каталога или что-то в этом роде. Я прочитал некоторые проблемы с аутентификацией kerberos, но я Пока не знаю, как это работает и почему у IE возникают проблемы.

Обновление 4 Я только что проверил запросы / ответы от моих товарищей по команде, и это выглядит примерно так же, они также используют аутентификацию NTLM, но они могут получить доступ к сайту с помощью Internet Explorer без изменения строки User Agent .

Обновление 5 Итак, мы получили миграцию домена для наших локальных учетных записей, кроме того, что мы не перешли через «другие сети» (мы работаем в Латинской Америке и мне кажется, что наш старый домен находился в Азии или что-то в этом роде, не получил много информации от ИТ-сторона) не знаю каких-либо других изменений, но теперь это работает. Тем не менее, если кто-то захочет поделиться какой-либо хорошей идеей о том, что могло быть возможным, изменилось или как это влияет на аутентификацию NTLM, я бы оценил комментарии / ответы.

Примечания Веб-сервер Apache Tomcat / 7.0.33 использует http-аутентификацию. Знаете ли вы / думаете ли вы, что это связано с разрешениями в активном каталоге? У меня есть имя сервера и IP-адрес, если это разрешение, какое разрешение я могу пропустить? При переключении User Agent на Chrome я не вижу заголовки NTLM на фиддлере. Почему у меня есть доступ с Chrome User Agent (без аутентификации NTLM), но не с IE (аутентификация NTLM) << обновление: после миграции домена у меня есть доступ с IE и использованием NTLMT auth >>?

0
Сайт, который вы посещаете, может обслуживать другой код в зависимости от строки пользовательского агента. Трудно устранить неполадки, не зная фактического сайта. Alistair McMillan 9 лет назад 0
Я полагал, что, но другие партнеры (кросс-кантри) могут просматривать сайт с той же версией IE, которую я использую, и alos с pac-прокси (в значительной степени тот же код). Сайт не является общедоступным (поэтому я использовал фиктивные имена). Так, чтобы свести мою проблему к IE или к прокси, или к обоим (я спрашиваю, меняли ли мои иностранные партнеры свой пользовательский агент с помощью IEM или с помощью реестра Windows, но я не получу ответ до следующей недели) Allende 9 лет назад 0
Когда вы говорите, что они используют одну и ту же версию IE, вы имеете в виду, что вы все на IE9? Потому что стоит проверить точную версию (например, 9.00.8112.16599). В прошлом у нас были случаи, когда все клиенты пользовались одной версией IE, но некоторые из них ломали свой браузер при посещении определенного сайта. Оказалось, что горстка не получала IE патчи. Alistair McMillan 9 лет назад 0
Мммм, мы должны быть в точно такой же версии, поскольку IE управляется централизованно, и мы должны установить одну и ту же версию, в любом случае, это подтвердится, поэтому я не пропускаю это, теперь это может быть проблемой, но Тем не менее, веб-страница / IE на самом деле не падает, я просто не могу просмотреть ее, когда IE 9 (9.0.8112.16421) использует строку User Agent по умолчанию Allende 9 лет назад 0
Я видел несколько примеров такого рода событий, и все они были проблемой на стороне сервера. Вы пытались использовать аддон IE, который подделывает пользовательский агент? Thebluefish 9 лет назад 0
Не аддон, но DevTools имеет возможность отправлять другую строку User Agent, когда я установил ее на использование «Chrome» (даже с Opera / Mozilla Firefox), IE может просматривать сайт, и на самом деле я понял, что с помощью Fiddler (также изменение агента пользователя). Я не думаю, что это проблема на стороне сервера, скорее всего, что-то в прокси, но сценарий прокси, используемый товарищами по команде в другой стране, выглядит почти так же, и сайт работает для них (не совсем они должны использовать IP вместо сервера имя), но я даже могу просматривать сайт с IP-адреса сервера Allende 9 лет назад 0
Я могу только думать, что IE + прокси (с аутентификацией) + httpd auth - это плохой рецепт (и владелец сервера отказался отключить http аутентификацию), но опять же нужно подтвердить, что мои товарищи по команде меняют свою строку User Agent с помощью IEM или используют Регистрация Windows и точная версия IE. Allende 9 лет назад 0
Другая вещь, которую вы можете сделать, это записать трафик с помощью чего-то вроде [Wireshark] (https://www.wireshark.org), а затем сравнить IE, используя свой собственный User Agent, с IE, используя другой User Agent. Это следующий шаг, который я сделаю. Alistair McMillan 9 лет назад 0
WireShark запрашивает «winpcap», который требует прав администратора для установки, не уверен, что можно использовать без него, я не знаком с WireShark, поэтому я проверил с помощью dev tools / neworkTab для IE, получил прерванный статус при использовании IE User Агент, когда установлен Chrome User Agent, запрос показывает статус 200 и веб-сайт отображается Allende 9 лет назад 0

0 ответов на вопрос