Полная Версия: Back или Front проверка данных?
| Цитата (twin @ 16.02.2014 - 18:28) | ||
Нафига на сервере проверять все и вся? Там вообще смый минимум проверок должен быть. |
да.. да.. жена.. презерватив.. помню, помню.
Хороший анекдот был, посмеялся вдоволь.
Только алигорию ты неверную привел.
Жена - она дома, и никакой законный пользователь дома, простите за каламбур, ей не навредит.
А вот если жена потаскушка - ну браузер, доступ извне.. то уже хозяин-барин, доверять ей, или на пороге "анализы" (валидация данных) ей устраивать.
Вот что в твоем понимании "Самый минимум проверок"?
Я ожидаю в GET-параметре число.
Проверять нужно?
А если ожидаю строку?
Проверять нужно?
А если я вообще данные из базы взял, их проверять перед выводом нужно?
Скажем, текст с html разметкой?
Скажи мне хоть на один вопрос "нет", и я обещаю, больше не реагировать на твои сообщения, т.к. это утопия.
А если на все вопросы ответ "да", то что же тогда НЕ ПРОВЕРЯТЬ?
_____________
[продано копирайтерам]
На сервере валидировать данные надо те, которые могут нарушить работу самого сервера, а остальное - забота клиентов. ИМХО.
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
chapaev
AllesKlar
Не знаю, кому отвечать. Обоим тогда, примерно одинаково рассуждаете.
Да вайте более подробно разберем некоторые примеры. потом будет проще понять.
Для начала - не нужно путать пользовтельскую влидацию и безопсность. Безопасность по идее к валидации имеет достаточно отдаленное отношение. Безопасность должна быть всегда. валидация совсем не обязательно. Согласитесь, глупо выдавать с сервера сообщение, мол извини, брат, но есть сомнение. что ты кулхацкер и мы не пустим твои данные в базу данных. На этом месте валидция заканчивается. Если человека на фронтэнде обо всем предупредили, а он окольными путями норовит засунуть чучу, тут два ваарианта.
1. Пропустить. Если это не вредит системе.
2. Не пустить. Просто. А то и забанить по IP, если попытки продолжатся. Зачем либеральничать.
Теперь несколько самых распространенных случаев.
Регистрация.
1. Логин. - Тут да, без сервера никак.
2. Пароль. Вполне достаточно проверить на клиенте. Если есть проверка на сложность или на повтор, то совершенно нет никакого смысла дергать сервер. Если человек обходит фронтэнд, ну его дело, пусть пишет пароль qwerty. Мы сделали что смогли, а навредить он один фиг не сможет никому, кроме как самому себе. Кроме того, я на незначимых ресурсах так и регаюсь. Меня сильно раздражают "заботливые" ресурсы, которые не пускают простых паролей.
3. Мыло. Ну проверять на соответствие маски можно и должно на клиенте. Зачем еще на сервере? Если человек захочет написать невалидный емайл, его никто не остановит:
paiodjep-wsdjskhdfowuhepwiehfwefwef-jhviyiyutcyutxsyrtszxtytygoligviu@jhjhjhjhjhjh.rr
Фильтр его посчитает правильным, толку с проверки на сервере? Куда рациональнее проверять его перед использовнием. В рассылке там или где.
4. День рождения. Поставить маску или селекты на клиенте - это красиво и удобно. На сервере для чего... Разве редко можно увидеть на форумах - возраст 110 лет. Кому хуже от этого? Если от этого что-то зависит, в этом только клиент заинтересован.
5. Телефон иногда. Все тоже самое. Маску поставили, помогли юзеру, все. Зачем дергать сервер, если кто-то идет в обход маски?
6. Текст какой-нибудь. Тут вообще никакой валидции быть не может. Ну максимум н клиенте - количество символов. На сервере безбожно отрезать.
7
8
9
Подавляющее большинство привычных проверок не нуждаются в дублировании. Единственно повторюсь, не путайте пользовтельскую валидацию и безопасность. Валидация, это подсказка или запрет. Безопасность, это обработка. Совершенно разные вещи.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
AllesKlar
Не знаю, кому отвечать. Обоим тогда, примерно одинаково рассуждаете.
Да вайте более подробно разберем некоторые примеры. потом будет проще понять.
Для начала - не нужно путать пользовтельскую влидацию и безопсность. Безопасность по идее к валидации имеет достаточно отдаленное отношение. Безопасность должна быть всегда. валидация совсем не обязательно. Согласитесь, глупо выдавать с сервера сообщение, мол извини, брат, но есть сомнение. что ты кулхацкер и мы не пустим твои данные в базу данных. На этом месте валидция заканчивается. Если человека на фронтэнде обо всем предупредили, а он окольными путями норовит засунуть чучу, тут два ваарианта.
1. Пропустить. Если это не вредит системе.
2. Не пустить. Просто. А то и забанить по IP, если попытки продолжатся. Зачем либеральничать.
Теперь несколько самых распространенных случаев.
Регистрация.
1. Логин. - Тут да, без сервера никак.
2. Пароль. Вполне достаточно проверить на клиенте. Если есть проверка на сложность или на повтор, то совершенно нет никакого смысла дергать сервер. Если человек обходит фронтэнд, ну его дело, пусть пишет пароль qwerty. Мы сделали что смогли, а навредить он один фиг не сможет никому, кроме как самому себе. Кроме того, я на незначимых ресурсах так и регаюсь. Меня сильно раздражают "заботливые" ресурсы, которые не пускают простых паролей.
3. Мыло. Ну проверять на соответствие маски можно и должно на клиенте. Зачем еще на сервере? Если человек захочет написать невалидный емайл, его никто не остановит:
paiodjep-wsdjskhdfowuhepwiehfwefwef-jhviyiyutcyutxsyrtszxtytygoligviu@jhjhjhjhjhjh.rr
Фильтр его посчитает правильным, толку с проверки на сервере? Куда рациональнее проверять его перед использовнием. В рассылке там или где.
4. День рождения. Поставить маску или селекты на клиенте - это красиво и удобно. На сервере для чего... Разве редко можно увидеть на форумах - возраст 110 лет. Кому хуже от этого? Если от этого что-то зависит, в этом только клиент заинтересован.
5. Телефон иногда. Все тоже самое. Маску поставили, помогли юзеру, все. Зачем дергать сервер, если кто-то идет в обход маски?
6. Текст какой-нибудь. Тут вообще никакой валидции быть не может. Ну максимум н клиенте - количество символов. На сервере безбожно отрезать.
7
8
9
Подавляющее большинство привычных проверок не нуждаются в дублировании. Единственно повторюсь, не путайте пользовтельскую валидацию и безопасность. Валидация, это подсказка или запрет. Безопасность, это обработка. Совершенно разные вещи.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
| Цитата (Invis1ble @ 16.02.2014 - 16:04) |
| На сервере валидировать данные надо те, которые могут нарушить работу самого сервера, а остальное - забота клиентов. ИМХО. |
Когда приложение полностью твое, то может быть. Но когда пишется API, а клиента пишет любой желающий, то такой подход не очень
_____________
Свои мозги еще никто не отменял.
Телепатов нету.
| Цитата |
| когда пишется API, а клиента пишет любой желающий, то такой подход не очень |
ты конечно прав, но я придерживаюсь все-таки позиции Сам себе злобный буратино, в случае, когда разработчик клиента не умеет читать документацию по API или у него попросту кривые руки.
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
Invis1ble
Да..да.. есть у меня такой. Весь мозг выел "У вас опять все криво работает".
Деньги-то уплочены, приходится тех-поддерживать.
Закончилось логированием абсолютно ВСЕХ вызовов + парсер логов.
Там видно, когда, откуда, каую функцию с API вызывали, какие параметры ей передавали, что API на этот ужас ответила.
Дурных вопросов уменьшилось примерно на 99%
И, кстати, "что API на этот ужас ответила" - вот тут и есть проверка и валидация всех входных параметров.
_____________
[продано копирайтерам]
Да..да.. есть у меня такой. Весь мозг выел "У вас опять все криво работает".
Деньги-то уплочены, приходится тех-поддерживать.
Закончилось логированием абсолютно ВСЕХ вызовов + парсер логов.
Там видно, когда, откуда, каую функцию с API вызывали, какие параметры ей передавали, что API на этот ужас ответила.
Дурных вопросов уменьшилось примерно на 99%
И, кстати, "что API на этот ужас ответила" - вот тут и есть проверка и валидация всех входных параметров.
_____________
[продано копирайтерам]
AllesKlar
| Цитата |
| Дурных вопросов уменьшилось примерно на 99% |
Вся беда в том, что эти дурные вопросы исчезают у одного, появятся у другого. Нельзя бороться со следствием, особенно таким образом. Бороться нужно с причинами. Это как если бы доктор рассказывал подробности анализов вместо того, чтобы прописать лекарство.
Валидацией кривизну приложения не победить. Я уже написал почему. Валидция, это проверка. А проверка может быть несовершенной - раз, излишняя и назойливая трепать нервы пользовтелю - два. От того жалобы, и как следствие, недовольство заказчика.
Так что тут подход должен быть индивидуальным. И никак нельзя заявлять, что валидировать на сервере нужно всё и вся. Наоборот. Валидации нужно как можно меньше. Не препоны двухярусные перед пользовтелем ставить, а вежливо подсказать, где действительно необходимо.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
Валидацией кривизну приложения не победить. Я уже написал почему. Валидция, это проверка. А проверка может быть несовершенной - раз, излишняя и назойливая трепать нервы пользовтелю - два. От того жалобы, и как следствие, недовольство заказчика.
Так что тут подход должен быть индивидуальным. И никак нельзя заявлять, что валидировать на сервере нужно всё и вся. Наоборот. Валидации нужно как можно меньше. Не препоны двухярусные перед пользовтелем ставить, а вежливо подсказать, где действительно необходимо.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
AllesKlar
ну так ты тут тоже ССЗБ
Т.к. согласился работать с клиентами на таких условиях, где виноват всегда ты
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
ну так ты тут тоже ССЗБ
Т.к. согласился работать с клиентами на таких условиях, где виноват всегда ты
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
Сорян за некропостинг. зацепило.
моя логика на этот счет такая:
- БД я хочу иметь порядок т.е. данные строго определенного формата (это существенно экономит нервы и время)
- Соответственно перед тем как пускать эти данные в базу я их буду проверять на сервере 100%
- Соответвенно роль JS проверки это сугубо user-friendly UI (к тому же далеко не все вещи можно вообще проверить на фронте например занятый email)
Конечно хочется выкинуть все проверки на JS и делать все на сервере т.е. гонять AJAX на каждый чих - но там траффика и нагрузки на сервер выйдет на порядок больше.
моя логика на этот счет такая:
- БД я хочу иметь порядок т.е. данные строго определенного формата (это существенно экономит нервы и время)
- Соответственно перед тем как пускать эти данные в базу я их буду проверять на сервере 100%
- Соответвенно роль JS проверки это сугубо user-friendly UI (к тому же далеко не все вещи можно вообще проверить на фронте например занятый email)
Конечно хочется выкинуть все проверки на JS и делать все на сервере т.е. гонять AJAX на каждый чих - но там траффика и нагрузки на сервер выйдет на порядок больше.
| Цитата (k11bytes @ 11.10.2019 - 19:27) |
| Сорян за некропостинг. |
Ну это да, археологом тебя можно смело назвать
| Цитата (k11bytes @ 11.10.2019 - 19:27) |
| моя логика на этот счет такая: - БД я хочу иметь порядок т.е. данные строго определенного формата (это существенно экономит нервы и время) - Соответственно перед тем как пускать эти данные в базу я их буду проверять на сервере 100% - Соответвенно роль JS проверки это сугубо user-friendly UI (к тому же далеко не все вещи можно вообще проверить на фронте например занятый email) |
Порядок в БД нужен, это точно. Даже если это окажется NoSQL, всё равно бардака надо избегать.
Проверка на фронте - да, чисто юзер-френдли. А проверка на бэке - уже полноценная проверка. Потому что с фронта могут прислать любую лабуду, обойдя все твои проверки. Ну это, естественно, если захотят.
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
Здесь расположена полная версия этой страницы.