Какое место для проверки входных данных?

Question

(Примечание: эти два вопроса похожи, но более специфичны для ASP.Net)

Рассмотрим типичное веб-приложение с расширенным клиентом (в моем случае это Flex), где у вас есть форма, базовая клиентская логика, которая отображает входные данные формы в модель данных, некоторый способ удаленного взаимодействия этих объектов с серверной логикой. , который обычно помещает его в базу данных.

Где я должен - вообще говоря - поставить логику валидации, т.е. е. обеспечение правильного формата адресов электронной почты, номеров и т. д .?

1. Как можно раньше. Обширные клиентские инфраструктуры, такие как Flex, предоставляют встроенную логику валидатора, которая позволяет выполнять проверку прямо при отправке формы, даже до того, как она достигнет вашей модели данных. Это приятно и быстро, но если вы разрабатываете что-то расширяемое и хотите, чтобы валидация защищала от ошибок программирования более поздних участников, это не уловило.
2. У модели данных на стороне клиента. Поскольку это «официальное» представление ваших данных, и у вас уже есть типы данных и получатели / установщики, эта проверка фиксирует ошибки пользователя и ошибки программирования от людей, расширяющих вашу систему.
3. После получения данных на сервере. Это добавляет защиту от сломанных или злонамеренных клиентов, которые могут присоединиться к системе позже. Также в сценарии с несколькими клиентами это дает вам один источник проверки.
4. Непосредственно перед сохранением данных в бэкэнде. Это включает в себя защиту от всех ошибок, допущенных в любом месте цепочки (кроме самой логики хранения), но может потребовать всплытия ошибки до конца.

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

Answer 1

Не вдаваясь в подробности, я думаю, что должны быть проверки по следующим причинам:

1. Сообщите пользователю, что ввод в некотором роде неверен.
2. Защита системы от атак.

Уведомление пользователя о том, что некоторые данные ранее неверны, было бы удобно - например, поле ввода электронной почты может иметь красный фон, пока не будет введен знак @ и имя домена. Только когда адрес электронной почты соответствует формату в RFC 5321/5322, поле электронной почты должно стать зеленым и, возможно, поставить небольшую галочку, чтобы пользователь знал, что адрес электронной почты выглядит хорошо.

Кроме того, информирование пользователя о том, что предоставленная информация, вероятно, в некоторой степени неверно, также будет полезно. Например, спросите пользователя, действительно ли он или она хочет иметь одного и того же получателя дважды для одного и того же сообщения электронной почты.

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

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

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

Я полагаю, что с моей точки зрения, к дружбе и обороне относятся.

Answer 2

Существует только правило, которое использует как минимум какой-то сервер проверки всегда (номер 3/4 в вашем списке).

Проверка клиента (номер 2/1) делает работу с пользователем более быстрой и снижает нагрузку (потому что вы не публикуете на сервере то, что не проходит проверку клиента).

Важно отметить, что если вы используете только проверку клиента, вы подвергаетесь большому риску (просто представьте, что проверка вашего клиента основана на javascript и пользователи отключают javascript в своем браузере).

Answer 3

Из соображений безопасности и удобства: на стороне сервера и как можно раньше Но также важно иметь некоторую глобальную проверку модели / бизнес-логики, поэтому, когда у вас есть, например, несколько форм с общими данными (например, название продукта), правило проверки должно оставаться согласованным, если в требованиях не указано иное.

Answer 4

На стороне сервера определенно должна быть проверка. Я думаю, что проверка должна быть выполнена как можно раньше на стороне сервера, чтобы меньше шансов на попадание вредоносных (или неверных) данных в систему.

Проверка входных данных на стороне клиента полезна, поскольку она делает интерфейс более быстрым, но нет гарантии, что данные, поступающие на сервер, прошли проверку на стороне клиента, поэтому ДОЛЖНА быть проверка на стороне сервера.