Каково надлежащее место для проверки входных данных?
Избегайте GetThumbnailImage - он даст очень непредсказуемые результаты, так как он пытается использовать встроенный эскиз JPEG, если он доступен, даже если встроенный эскиз совершенно неправильного размера. DrawImage () - гораздо лучшее решение.
Оберните ваше растровое изображение в предложение using {} - вы не хотите, чтобы пропущенные дескрипторы плавали вокруг ...
Кроме того, вы захотите установить качество кодирования Jpeg на 90, и именно здесь GDI + выглядит лучше всего:
System.Drawing.Imaging.ImageCodecInfo[] info = System.Drawing.Imaging.ImageCodecInfo.GetImageEncoders();
System.Drawing.Imaging.EncoderParameters encoderParameters;
encoderParameters = new System.Drawing.Imaging.EncoderParameters(1);
encoderParameters.Param[0] = new System.Drawing.Imaging.EncoderParameter(System.Drawing.Imaging.Encoder.Quality, 90L);
thumb.Save(ms, info[1], encoderParameters);
4 ответа
Не вдаваясь в подробности, я думаю, что необходимы проверки по следующим причинам:
- Сообщите пользователю, что введенные данные каким-то образом неверны.
- Защитите систему от атак.
Предупреждать пользователя о том, что некоторые данные неверны, было бы удобно - например, поле ввода электронной почты может иметь красный фон до тех пор, пока не будет введен знак @ и доменное имя. Только когда адрес электронной почты соответствует формату в RFC 5321/5322, поле электронной почты должно стать зеленым и, возможно, поставить небольшую галочку, чтобы пользователь знал, что адрес электронной почты выглядит хорошо.
Кроме того, было бы полезно сообщить пользователю, что предоставленная информация, вероятно, в некотором роде неверна. Например, спросите пользователя, действительно ли он хочет иметь одного и того же получателя дважды для одного и того же сообщения электронной почты.
Затем следует проверить на стороне сервера - и никогда не предполагать, что данные, которые проходят правильно сформирован. Выполняйте проверки, чтобы убедиться, что данные верны, и остерегайтесь любых атак.
Предположение, что клиент будет препятствовать внедрению SQL, и слепой прием данных от подключений к серверу может быть серьезной уязвимостью. Как уже упоминалось, злонамеренный клиент, единственная цель которого - атаковать систему, может легко скомпрометировать систему, если сервер был слишком доверчивым.
И, наконец, выполните любые проверки, чтобы убедиться, что данные верны, и логика может справиться с данные правильно. Если есть какие-то проблемы, уведомляйте пользователя о любых проблемах.
Я думаю, что все сводится к дружелюбию и защите,
Есть только правило, которое всегда использует как минимум какую-то проверку сервера (номер 3/4 в вашем списке).
Проверка клиента (номер 2/1) делает взаимодействие с пользователем более быстрым и снижает нагрузку (потому что вы не отправляете на сервер данные, которые не проходят проверку клиента).
Важно отметить выход в том, что если вы идете только с проверкой клиента, вы подвергаетесь большому риску (только представьте, если ваша проверка клиента полагается на javascript, а пользователи отключают javascript в своем браузере).
На стороне сервера определенно должна быть проверка. Я думаю, что проверка должна проводиться как можно раньше на стороне сервера, чтобы уменьшить вероятность попадания злонамеренных (или неверных) данных в систему.
Проверка ввода на стороне клиента полезна, поскольку она делает интерфейс быстрее, но нет гарантии, что данные, поступающие на сервер, прошли проверку на стороне клиента,
Из соображений безопасности и удобства: на стороне сервера и как можно раньше насколько возможно Но также важно иметь некоторую валидацию глобальной модели / бизнес-логики, поэтому, когда у вас есть, например, несколько форм с общими данными (например, название продукта), правило валидации должно оставаться согласованным, если в требованиях не указано иное.