JavaScript: проверка на стороне клиента и на стороне сервера

Ответ 1

Как уже говорили другие, вы должны сделать оба. Вот почему:

Клиентская сторона

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

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

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

Сторона сервера

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

Очень опасно доверять вашему интерфейсу. Они могут не только злоупотреблять вашим пользовательским интерфейсом, но и вообще не использовать ваш пользовательский интерфейс или даже браузер. Что если пользователь вручную отредактирует URL-адрес, запустит собственный Javascript или настроит свои HTTP-запросы с помощью другого инструмента? Что если они отправят пользовательские HTTP-запросы из curl или из сценария, например?

(Это не теоретически; например, я работал над поисковой системой путешествий, которая повторно отправляла поиск пользователей во многие авиакомпании-партнеры, автобусные компании и т.д., Отправляя запросы POST, как если бы пользователь заполнил каждую форму поиска компании, затем собрал и отсортировал все результаты. Форма этих компаний JS никогда не выполнялась, и для нас было важно, чтобы они предоставляли сообщения об ошибках в возвращенном HTML. Конечно, API был бы хорош, но это было то, что мы должны были сделать.)

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

Проверка на стороне сервера также важна для совместимости - не всем пользователям, даже если они используют браузер, будет включен JavaScript.

Приложение - декабрь 2016 г.

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

Ответ 2

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

Ответ 3

Я просто повторю это, потому что это очень важно:

Всегда проверяйте на сервере

и добавьте JavaScript для пользовательской реакции.

Ответ 4

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

• Конечный пользователь может отключить javascript.
• Данные могут быть отправлены непосредственно на ваш сервер кем-то, кто даже не использует ваш сайт, с настраиваемым приложением, предназначенным для этого.
• Ошибка Javascript на вашей странице (вызванная любым количеством вещей) может привести к некоторым, но не всем, к проверке вашей работы

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

Ответ 5

Вы всегда должны проверять на сервере.

Кроме того, проверка подлинности на клиенте хороша для пользователей, но совершенно небезопасна.

Ответ 6

Ну, я все еще найду какую-то комнату для ответа.

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

Client-Side

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

на стороне сервера

• НЕ ДОЛЖЕН предполагать, что проверка, выполненная на стороне клиента, на 100% идеальна. Неважно, даже если он обслуживает менее 50 пользователей. Вы никогда не знаете, какой из ваших пользователей /emplyee превращается в "зло" и совершает какую-то вредную деятельность, зная, что у вас нет надлежащих валидаций.
• Даже если он совершенен с точки зрения проверки адреса электронной почты, телефонных номеров или проверки правильных входов, он может содержать очень вредные данные. Который должен быть отфильтрован на стороне сервера, независимо от его правильности или неправильности.
• Если проверка на стороне клиента обойдена, ваши проверки на стороне сервера помогут вам избавиться от любого возможного повреждения вашей серверной обработки. В последнее время мы уже слышали много историй о SQL Injections и других методах, которые могут быть применены для получения некоторых злых преимуществ.

Оба типа валидации играют важную роль в их соответствующей области, но наиболее сильным является серверная сторона. Если вы получаете 10 тыс. Пользователей в один момент времени, то вы, несомненно, в конечном итоге отфильтровываете количество запросов, поступающих на ваш веб-сервер. Если вы обнаружите, что произошла одна ошибка, например, неверный адрес электронной почты, они снова отправляют форму и просят пользователя исправить ее, что определенно будет использовать ресурсы вашего сервера и пропускную способность. Поэтому лучше применять проверку JavaScript. Если javascript отключен, ваша проверка на стороне сервера придет на помощь, и я ставлю, что только несколько пользователей могут случайно отключить его, поскольку 99,99% веб-сайтов используют javascript и уже включены по умолчанию во всех современных браузерах.

Ответ 7

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

Ответ 8

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

Ответ 9

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

Вы можете найти соответствующую информацию здесьhttps://web.archive.org/web/20131210085944/http://www.webexpertlabs.com/server-side-form-validation-using-regular-expression/

Ответ 10

JavaScript может быть изменен во время выполнения.

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

Вам потребуется отдельная логика проверки на обоих концах, например:

"required" атрибуты inputs на стороне клиента

field.length > 0 на стороне сервера.

Но использование одной и той же спецификации валидации устранит некоторую избыточность (и ошибки) проверки зеркалирования на обоих концах.

Ответ 11

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

Client-Side validation идеально подходит для предотвращения грубых и случайных ошибок. Обычно максимальная длина текстуры и ввода. Не имитируйте правило проверки на стороне сервера; предоставить собственное правило валидности, правило проверки правильности большого пальца (например, 200 символов на стороне клиента; n на стороне сервера, продиктованное сильным бизнес-правилом).

Server-side validation идеально подходит для предотвращения систематических ошибок; он будет обеспечивать соблюдение бизнес-правил.

В проекте, в котором я участвую, проверка выполняется на сервере через ajax-запросы. На клиенте я отображаю сообщения об ошибках соответственно.

Дальнейшее чтение: грубые, систематические, случайные ошибки:

https://answers.yahoo.com/question/index?qid=20080918203131AAEt6GO

Ответ 12

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

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

Ответ 13

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