Запрашивает учетные данные AD / «Соединение прервано» при обратной передаче - PullRequest
2 голосов
/ 04 августа 2009

Много подведено:

У меня есть простая веб-форма для ввода данных ASP .NET 3.5 с серией раскрывающихся списков, текстовых полей и текстовых областей, а проверка подлинности пользователя выполняется Active Directory.

Пользователь вводит буквенно-цифровой идентификатор и нажимает кнопку. Кнопка onclick () в aspx.cs:
1. вызывает хранимую процедуру, чтобы определить, является ли она новой записью или существующими данными, если она уже существует
2. если запись существует, то предварительно заполняет форму существующими значениями.

Существует три текстовых поля, которые были расширены для использования ASP .NET AJAX AutoComplete (каждое из которых содержится в собственном asp: UpdatePanel), которые также успешно выполняют обратную передачу.

Когда пользователь заканчивает ввод данных, существует единственная кнопка для сохранения записи, которая:
1. вызывает хранимую процедуру, которая либо вставляет, либо обновляет соответственно
2. очищает веб-форму
3. отображает быстрое сообщение об успехе.

С момента запуска этой формы было добавлено и обновлено более 4000 записей. У меня возникла проблема, когда существует запись ONE , которую невозможно обновить, она была вставлена ​​месяц назад через ту же форму без проблем.

В Internet Explorer (6, 7 и 8): Когда вы нажимаете кнопку «Сохранить», он запрашивает у вас имя пользователя и пароль для вашего домена. При вводе правильного имени пользователя и пароля отображается экран «Internet Explorer не может отобразить веб-страницу».

В Firefox 3: При нажатии кнопки сохранения отображается экран «Соединение прервано». Нажатие кнопки «Повторить попытку» не меняет результаты.

Нет записей в журнале, который использует приложение, журнал событий сервера или для SQL Server 2005.

Я пробовал:
- на разных компьютерах, и это не удалось.
- с разными пользователями, и это не удалось.
- с многочисленными другими записями, и они прекрасно обновляются.

Я загрузил запись в тестовую среду двумя различными способами:
1. скопированы и вставлены непосредственно из рабочей базы данных в тестовую базу данных
2. скопировать и вставить непосредственно из рабочей веб-формы в тестовую веб-форму.
Проблема не возникает ни в тесте, ни в моей локальной системе разработки. И на производстве, и на тестировании работает ASP .NET 3.5 SP1.

Я даже сохранил копию рабочей страницы, которая не работает, и тестовую страницу, которая работает как HTML, и запустил их с помощью функции «Сравнить файлы по содержимому» в Total Commander в надежде, что различия будут выделены красным, чтобы красиво и очевидно. Единственные различия были в областях, автоматически сгенерированных .NET во время выполнения, и в случайном месте, где в выпадающем списке элементов больше записей, чем в тесте.

Я понимаю, что, возможно, что-то не так с данными, которые приводят к сбою окончательной обратной передачи, но, похоже, происходит сбой еще до ее запуска. Я просматривал данные записи, просматривая источник загруженной страницы aspx и в базе данных в надежде найти случайный невидимый символ или текстовое поле, в котором слишком много символов, которые могут вызывать его удушение, но не повезло.

Сотрудник предложил установить viewStateEncryptionMode="never" в web.config, и это «исправило» проблему, и теперь запись может быть обновлена ​​без ошибок.

К сожалению, я не могу предоставить данные, которые приводят к сбою формы.

Мой вопрос: У кого-нибудь есть идея, почему это произошло в первую очередь или почему установка viewStateEncryptionMode="never" исправила это? Лучшее решение, чем установка ViewStateEncryptMode никогда, также приветствуется.

Спасибо!

1 Ответ

1 голос
/ 04 августа 2009

Во-первых, и самое главное - помимо .Net 3.5 SP1 - убедитесь, что на сервере установлены последние исправления (это всегда должно быть первым шагом).

Предполагая, что сервер обновлен, я бы начал с проверки брандмауэра и антивирусного программного обеспечения на вашем сервере (они должны иметь журналы). Антивирус может блокировать веб-сайты, которые используют подозрительный код - как, например, известный эксплойт JavaScript (я признаю, что пробовал этот. Для науки). Возможно, определенная комбинация в состоянии просмотра выглядит как подозрительный код или файл (кажется странным, но возможно).
Далее вы можете проверить IIS. Включите ведение журнала и посмотрите, нет ли ошибок. Проверьте, установлены ли у вас какие-либо фильтры isapi (они могут находиться в нескольких местах - в папке «Расширения веб-службы» или на вкладке Properties на веб-сайте или в одном из его родительских свойств)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...