Предотвращение неправильного ввода данных

Question

Является ли хорошей практикой полностью делегировать проверку данных ограничениям механизма базы данных?

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

Если вы ставите проверку как в базе данных, так и в приложении, обслуживание становится скучным, потому что вам нужно обновить код, который знает, сколько приложений, увеличивая вероятность человеческих ошибок.

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

Answer 1

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

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

Paranoid? Мне? Нет, только что испытал.

Answer 2

Лучше, когда это возможно, чтобы ваши правила проверки были указаны в вашей базе данных, и использовать или написать структуру, которая заставит эти правила всплывать в вашем интерфейсе. ASP.NET Dynamic Data помогает в этом, и есть некоторые коммерческие библиотеки, которые делают это еще проще.

Это можно сделать как для простой проверки ввода (например, чисел или дат), так и для связанных данных, подобных тем, которые ограничены внешними ключами.

Таким образом, идея состоит в том, чтобы определить правила в одном месте (в большинстве случаев это база данных) и иметь код на других уровнях, который будет обеспечивать соблюдение этих правил.

Answer 3

Уже слишком поздно, когда данные попадают в вашу базу данных, чтобы обеспечить значительную проверку для ваших пользователей и приложений. Вы не хотите, чтобы ваша база данных выполняла все проверку, так как это очень сильно замедлит работу, а база данных не будет так четко выражать логику. Точно так же, по мере роста вы будете писать больше транзакций уровня приложения, чтобы дополнять транзакции базы данных.

Answer 4

Существуют и другие проблемы, а не только SQL-инъекция с вводом. Вы должны принимать максимально защитную позицию, когда принимаете ввод пользователя. Например, пользователь может ввести ссылку на изображение в текстовое поле, которое на самом деле представляет собой PHP-скрипт, выполняющий что-то неприятное.

Если вы хорошо разрабатываете свое приложение, вам не нужно кропотливо проверять все входные данные. Например, вы можете использовать Forms API, который выполняет большую часть работы за вас, и слой базы данных, который делает то же самое.

Это хороший ресурс для базовой проверки уязвимостей:

http://ha.ckers.org/xss.html

Answer 5

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

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

Answer 6

Я не думаю, что есть один правильный ответ, это зависит от вашего использования.

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

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

Вам может потребоваться более плавный экран ввода, который не просто поражает пользователя предупреждениями о проверке, когда они пытаются сохранить запись, может быть, вы хотите проверить поле после ввода данных и потери фокуса; или даже когда пользователь вводит текст, изменение цвета шрифта по мере того, как проверка не проходит / проходит успешно.

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

Answer 7

Я обнаружил, что проверка в приложении, а не в базе данных, работает хорошо. Конечно, все взаимодействие должно проходить через ваше приложение. Если у вас есть другие приложения, которые работают с вашими данными, ваше приложение должно будет поддерживать некоторый вид API (надеюсь, REST).

Answer 8

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

Answer 9

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

Answer 10

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

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