JavaScript: перевірка на стороні клієнта порівняно з сервером

Що краще зробити для клієнта чи сервера?

У нашій ситуації ми використовуємо

• jQuery та MVC.
• Дані JSON, що передаються між нашим представленням даних та контролером.

Багато валідації, яку я роблю, - це перевірка даних, коли користувачі вводять її. Наприклад, я використовую keypressподію для запобігання букв у текстовому полі, встановлюю максимальну кількість символів, а число - у діапазоні.

Я думаю, що краще питання було б: Чи є якісь переваги у виконанні перевірки на сервері на стороні клієнта?

Чудово відповідають всі. Веб-сайт, який ми маємо, захищений паролем і для невеликої бази користувачів (<50). Якщо вони не працюють на JavaScript, ми надішлемо ніндзя. Але якби ми розробляли сайт для кожного, я погодився б зробити перевірку з обох сторін.

Як говорили інші, ви повинні робити і те, і інше. Ось чому:

Сторона клієнта

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

Якщо ви підтверджуєте лише сервер, вони повинні надіслати форму, отримати повідомлення про помилку та спробувати усунути проблему.

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

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

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

Дуже небезпечно довіряти своєму інтерфейсу. Вони не тільки можуть зловживати вашим інтерфейсом, але можуть взагалі не використовувати ваш інтерфейс або навіть браузер . Що робити, якщо користувач вручну редагує URL-адресу або запускає свій власний Javascript, або налаштовує свої HTTP-запити іншим інструментом? Що робити, якщо, наприклад, вони надсилають власні HTTP-запити зі curlскрипту чи з нього?

( Це не теоретично; наприклад, я працював над пошуковою системою подорожей, яка повторно надсилала пошук користувача багатьом авіакомпаніям-партнерам, автобусним компаніям тощо), надсилаючи POSTзапити так, ніби користувач заповнив форму пошуку кожної компанії, потім зібрав і сортував. всі результати. Форма JS цих компаній ніколи не виконувалася, і для нас було вирішальним те, що вони надають повідомлення про помилки у поверненому HTML. Звичайно, API було б непогано, але це було те, що ми повинні зробити. )

Не допускаючи цього, це не тільки наївно з точки зору безпеки, але й нестандартно: клієнту слід дозволити надсилати HTTP будь-якими способами, які вони хочуть, і ви повинні правильно відповісти. Це включає перевірку.

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

Додаток - грудень 2016 року

Існують деякі перевірки, які неможливо виконати належним чином у коді додатка на сервері, і зовсім неможливо в коді клієнта , оскільки вони залежать від поточного стану бази даних. Наприклад, "ніхто інший не зареєстрував це ім'я користувача", або "допис у блозі, який ви коментуєте, все ще існує", або "жодне існуюче бронювання не перекриває вказані вами дати", або "залишок у вашому обліковому записі ще достатньо, щоб покрити цю покупку . " Лише база даних може надійно перевірити дані, що залежать від пов'язаних даних. Розробники регулярно вкручують це , але PostgreSQL надає хороші рішення .

Так, перевірку на стороні клієнта завжди можна повністю обійти. Вам потрібно зробити і те, і клієнтське, щоб забезпечити кращу взаємодію з користувачем, і сторону сервера, щоб бути впевненим, що отримані вами дані дійсно підтверджені, а не просто нібито підтверджені клієнтом.

Я просто повторю це, бо це дуже важливо:

Завжди перевіряйте на сервері

і додайте JavaScript для чутливості користувачів.

Перевага валідації на стороні сервера над валідацією на стороні клієнта полягає в тому, що перевірку на стороні клієнта можна обійти / маніпулювати:

• Кінцевий користувач міг вимкнути javascript
• Дані можуть бути надіслані безпосередньо на ваш сервер тим, хто навіть не використовує ваш сайт, за допомогою спеціального додатка, призначеного для цього
• Помилка Javascript на вашій сторінці (викликана будь-якою кількістю речей) може призвести до деяких, але не всіх, вашої перевірки перевірки

Коротше кажучи - завжди завжди перевіряйте серверну сторону, а потім розглядайте перевірку на стороні клієнта як додаткову «додаткову» для покращення роботи кінцевого користувача.

Ви завжди повинні перевірити на сервері.

Також перевірка на клієнті є приємною для користувачів, але є абсолютно незахищеною.

Ну, я все одно знаходжу місце для відповіді.

На додаток до відповідей Роб та Натана, я додам, що питання перевірки на стороні клієнта має значення. Коли ви застосовуєте перевірки на своїх веб-формах, ви повинні дотримуватися цих вказівок:

Клієнтська сторона

1. Потрібно використовувати перевірки на стороні клієнта для фільтрації справжніх запитів від справжніх користувачів на вашому веб-сайті.
2. Перевірка на стороні клієнта повинна використовуватися для зменшення помилок, які можуть виникнути під час обробки на стороні сервера.
3. Перевірка на стороні клієнта повинна використовуватися для мінімізації зворотних маршрутів на стороні сервера, щоб заощадити пропускну здатність та запити на кожного користувача.

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

1. Ви НЕ БУДЕТЕ припускати, що перевірка, успішно виконана на стороні клієнта, на 100% досконала. Неважливо, навіть якщо він обслуговує менше 50 користувачів. Ви ніколи не знаєте, хто з ваших користувачів / emplyee перетворюється на "зла" і робить якусь шкідливу діяльність, знаючи, що у вас немає належних перевірок.
2. Навіть якщо це ідеально з точки зору перевірки електронної адреси, телефонних номерів або перевірки деяких дійсних входів, воно може містити дуже шкідливі дані. Який потрібно фільтрувати на стороні сервера, незалежно від того, правильний він чи неправильний.
3. Якщо перевірка на стороні клієнта обійдена, валідації на стороні сервера врятують вас від можливого пошкодження вашої обробки сервера. Останнім часом ми вже чули багато історій про ін'єкції SQL та інших видів методик, які можуть бути застосовані для отримання корисних вигод.

Обидва типи перевірок грають важливу роль у відповідному обсязі, але найбільш сильною є серверна. Якщо ви отримаєте 10 тис. Користувачів за один момент часу, то ви обов'язково фільтруєте кількість запитів, які надходять до вашого веб-сервера. Якщо ви виявили одну помилку, як недійсна адреса електронної пошти, вони знову надсилають форму і просять вашого користувача виправити її, яка обов'язково з'їсть ресурси вашого сервера та пропускну здатність. Тож краще застосувати перевірку javascript. Якщо javascript відключений, тоді перевірка вашої серверної системи допоможе, і я думаю, що лише деякі користувачі можуть випадково відключити його, оскільки 99,99% веб-сайтів використовують javascript і його вже включено за замовчуванням у всіх сучасних браузерах.

Ви можете виконати перевірку на стороні сервера та відправити назад об'єкт JSON з результатами перевірки для кожного поля, зведення клієнтського Javascript до мінімуму (лише показ результатів) та все-таки зручність у користуванні, не повторюючись на клієнті та сервері.

Сторона клієнта повинна використовувати базову перевірку за допомогою вхідних типів HTML та атрибутів шаблону HTML5, оскільки вони використовуються лише для прогресивних удосконалень для кращого користувацького досвіду (Навіть якщо вони не підтримуються в <IE9 та сафарі, але ми не покладаємося на них). Але основна перевірка повинна відбуватися на стороні сервера ..

Я запропоную здійснити і клієнтську, і серверну перевірку, вона підтримує проект більш захищеним ...... якщо мені доведеться вибрати один, я піду з валідацією на стороні сервера.

Інформацію можна знайти тут https://web.archive.org/web/20131210085944/http://www.webexpertlabs.com/server-side-form-validation-using-regular-expression/

JavaScript можна змінювати під час виконання.

Я пропоную схему створення структури перевірки на сервері та обміну цим із клієнтом.

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

"required"атрибути на inputsстороні клієнта

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

Але використання однієї і тієї ж специфікації перевірки усуне деяку надмірність (і помилки) перевірки дзеркального відображення на обох кінцях.

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

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

Я натрапив на цікаве посилання, яке розрізняє грубі, систематичні, випадкові помилки.

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

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

У проекті, в якому я беру участь, перевірка виконується на сервері за допомогою ajax-запитів. На клієнті я відображаю повідомлення про помилки відповідно.

Подальше читання: грубі, систематичні, випадкові помилки:

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

Якщо ви робите легку перевірку, найкраще це зробити на клієнті. Це заощадить мережевий трафік, що допоможе вашому серверу краще працювати. Якщо це складна перевірка, яка передбачає витяг даних з бази даних або щось подібне, наприклад, паролі, то найкраще це зробити на сервері, де дані можна надійно перевірити.