Я знаю, что никогда не доверяю пользовательскому вводу, поскольку нежелательный вход может каким-то образом скомпрометировать целостность приложения, будь то случайным или преднамеренным; однако, существует ли случай для вызова Page.IsValid, даже если на странице нет элементов управления проверкой (опять же, я знаю, что его плохая практика - доверять пользовательским вводам, не допуская проверки)? Выполняет ли Page.IsValid любые другие виды проверки? Я посмотрел на MSDN, и документы, похоже, предполагают, что Page.IsValid эффективен только в том случае, если на странице есть элементы управления проверкой или вызван метод Page.Validate. Один мой друг предположил, что я всегда проверяю Page.IsValid в обработчиках щелчков кнопок каждый раз, даже если нет элементов управления проверкой или явных вызовов Page.Validate.
Должен ли я всегда называть Page.IsValid?
Ответ 1
Я был бы первым, кто сказал бы вам, что "Все входные данные являются злыми, пока не будет доказано иное". Однако в этом случае, я думаю, ваш друг ошибается, потому что по своей логике мы могли бы, вероятно, придумать сотню других свойств, которые должны быть проверены или установлены, хотя значения по умолчанию в порядке.
Проверка Page.IsValid имеет смысл только в том случае, если у вас есть сценарий "CausesValidation" - кнопка, которая отправила форму, имеет свойство CausesValidation, установленное в True. Это автоматически вызовет Page.Validate, и все проверки, принадлежащие тому же ValidationGroup, будут проверены на достоверность.
Edit:
Просто проверил его с помощью Reflector, и функция всегда вернет True, если на странице нет никаких валидаторов (ValidatorCollection - null).
Ответ 2
Вы можете проверить достоверность страницы, проверив свойство Page.IsValid, ваша цель проверить значение параметра Page.IsValid может отличаться от
- Если у вас есть Validators, у которого свойство EnableClientScript установлено на false
- Если у вас есть проверенный валидатор на стороне сервера.
- Перед выполнением критической операции в обработчике событий PostBack, таком как Save, Delete, Authenticate...
- Делать/показывать разные вещи в зависимости от действительности страницы...
- Любая вещь, о которой вы можете думать...
Итак, когда/где вы можете позвонить Page.IsValid
- Если страница находится в обратном порядке
- Если пост-ответ вызван элементом управления вводом, свойство CausesValidation установлено в true.
- После того, как вызов сделан в Page.Validate, т.е. после события Page.Load.
Вы можете проверить Page.IsValid в жизненном цикле страницы, если вызванное место/время удовлетворяет вышеуказанным критериям; иначе page.IsValid приведет к выбросу System.Web.HttpException.
Вы должны использовать Page.IsValid, где это имеет смысл; например, в обработчиках событий postback входных элементов управления (с CausesValidation = true) и требуют правильного состояния страницы для правильной работы их задачи. (если у вас есть проверенные валидаторы или валидаторы на стороне сервера с отключенной проверкой на стороне клиента, он становится ДОЛЖНЫ).
protected void btnSave_Click(object sender, EventArgs e)
{
//Note that there might be ServerSideValidation which evaluated to false.
if (!Page.IsValid)
return;
CurrentEntity.Save();
}
Наконец, обратите внимание, что Page.IsValid проверяет только ошибки проверки в элементах проверки подлинности на вашей странице, все зависит от того, что делают ваши контролеры проверки.
Ответ 3
Вы все еще можете назвать это, потому что в будущем они могут быть проверены. Я знаю, что этот вид сводится к добавлению функциональности, основанной на будущих требованиях, но он также защищает вас от необходимости знать, является ли страница действительной и не проходит через все обработчики событий и т.д., Чтобы убедиться, что она есть, если валидатор действительно получает добавлено. У нас есть правило, которое мы всегда добавляем, поэтому у нас нет этой проблемы, которая не подтверждается в будущем.