Избегайте ответа 401 на каждый запрос, используя NTLM

StackOverflow https://stackoverflow.com/questions/1222506

Вопрос

Здесь у нас есть приложение asp.net 3.5, использующее проверку подлинности Windows на основе NTLM. Система работает в частной сети, которая фактически распределена по разным географическим местам (подключенным через VPN).

Сейчас мы пытаемся оптимизировать работу сайта. Поскольку работает NTLM, каждый новый запрос к IIS состоит из 3 разных запросов, а первые 2 - 401 ответа. Мы пытаемся свести к минимуму количество этих запросов только в начале сеанса. Мы нашли это решение. К сожалению, это ничего не изменило, и мы продолжаем получать этот ответ 401 (который занимает время).

Чтобы увидеть трафик, я сначала использовал приложение Fiddler. Каким-то образом, когда я использую Fiddler, в начале сеанса происходит только 1 процесс аутентификации (именно так, как я хочу), но когда я закрываю Fiddler и проверяю трафик через WireShark, я вижу, что у меня все еще есть этот ответ 401 для каждого запроса .

Используются клиенты IE6, IIS версии 6.

Может кто-нибудь посоветовать?

Это было полезно?

Решение

NTLM / Negotiate, в отличие от всех других схем аутентификации HTTP, являются протоколами, ориентированными на соединение.

В IIS существуют различные настройки, которые определяют, будет ли требоваться аутентификация для всех запросов в ранее аутентифицированном соединении (например, AuthPersistSingleRequest). Я полагаю, что независимо от этого параметра IIS автоматически потребует повторной аутентификации при выполнении запроса POST.

Если ваш сервер препятствует повторному использованию соединения (например, отправляя заголовок Connection: закрыть заголовок в ответах), вы должны исправить это, потому что в противном случае произойдет повторная аутентификация. Вы можете легко проверить наличие таких повторяющихся заголовков аутентификации, используя Fiddler.

Другие советы

Единственный способ - использовать NTLM только на странице входа в систему и использовать файлы cookie, такие как здесь <

Вы пробовали это в своем домене?

setspn -a FQDNServerName applicationPoolServiceAccount
setspn -a biosServerName applicationPoolServiceAccount

Позволяет пулу приложений обслуживать запросы аутентификации NTLM.

Это могут быть ваши настройки безопасности в IE6 для сайта. Попробуйте перейти на локальный интранет или доверенный сайт.

У меня точно такая же проблема! Я использую ту же среду, что и вы. За исключением того, что я вижу 2 401 даже в Fiddler. Я потратил пару дней на эту проблему, а затем просто сдался. AuthPersistence у меня тоже не сработало. Но вот ссылки, которые я нашел, возможно, они будут работать в вашем случае.

http://msdn.microsoft.com/en-us/library /ms525244.aspx

http://www.microsoft.com/technet/prodtechnol/WindowsServer2003 /Library/IIS/b0b4ec5c-74f8-43e9-ac64-d8b852568341.mspx?mfr=true

http://technet.microsoft.com/en-us/library /cc786094.aspx

http://technet.microsoft.com/en-us/library /cc781339(WS.10).aspx

Я пытался установить флаг как на уровне виртуального каталога, так и на уровне веб-сайта, но это не помогло. Используете ли вы IIS Metabase Explorer для редактирования этих свойств? Это более чистый способ редактирования свойств и может помочь не только непосредственное редактирование файла XML.

Один из способов обойти эту проблему - вставить заголовок Cache-Control в HTTP-ответ для ресурсов, которые не будут часто меняться ни на одной странице. В моем случае я кешировал css (максимально используйте внешние css для оптимизации), js и img файлы. Поскольку у меня есть около 60 файлов этих типов, которые загружаются на нашу домашнюю страницу, мы смогли сразу устранить около 120 401 ошибок!

Убедитесь, что вы используете заголовок Cache-Control, а не кэширование с модифицированным или электронным тегом, где 401 и 304 будут генерироваться, даже когда файлы кэшируются.

У меня тоже была эта проблема, за исключением того, что для меня это были в основном файлы JS и CSS. Мой сайт (как и большинство сайтов) хранит файлы JS и CSS в своих собственных каталогах. Поэтому решение для меня было просто перейти в эти каталоги в IIS и включить Anon Auth (я говорю просто, но мне потребовалось два года, чтобы разобраться с этим; благодаря этому посту). Теперь сайт все еще требует аутентификации Windows, а подкаталоги для файлов JS и CSS - нет. IOW, кажется, работает отлично.

Я также никогда бы не поместил конфиденциальную информацию в файл JS (или CSS-файл в этом отношении) и предложил бы, чтобы вы тоже этого не делали. Если вы это сделаете, вы, очевидно, захотите переместить конфиденциальную информацию в этих файлах из этих каталогов.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top