Собственно вопрос по сабжу. Тема, наверное, избитая.

----------------------------------
Вводная:
----------------------------------
Представим себе серьёзный ресурс, разработанный по MVC.
Обычным сайтом это сложно назвать. Назовём его апи-ориентированным веб-приложением.

Делается ресурс с такими планами, что в будущем бэковая часть его будет апи-ориентированная, то есть один единый функционал, и будет множество клиентов (назовём их "тонкими клиентами", которые должны лишь дёргать за рычаги апи) например - мобильное приложение под андроид, та же веб-морда самого сайта, какой-то windows-клиент etc.

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

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

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

Но тут два момента:
1. Никому не помешает направить пост-запрос в обход JavaScript-кода. Получается, что это всего лишь защита от дурака. Да и защитой нельзя назвать толком, а всего лишь удобство.
2. Делается ведь с целью в будущем писать клиенты под разные платформы, оставив логику на php, то есть они все обязаны будут контролировать вводимые пользовательские данные. А это есть дублирование.

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

Смешивая же проверки на фронте и бэке - будет избыточность.
На форме JavaScript'ом проверил на запрещённые символы, в приложении под андроид java-кодом проверил, повторил эту же проверку на php-скрипте.

Где найти тот заветный правильный баланс?

_____________
"О наших провалах знает весь мир, о наших победах не знает никто." ЦРУ

chapaev
Проверку делаешь и там и там.

_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).

То есть, рассматривать каждый модуль критически?

Если, к примеру, символ шарп не должен попадать в базу, то нужно проверить сперва на JS, потом его же проверить на "апи php"?

Так сказать, рассматривать каждый модуль как "хрупкую систему" и навешивать проверки на всех этапах, разве что только какой-то слой не упрятан в "чёрный ящик" (например операторы sql, для которых проверку входящих данных можно организовать на уровне php, оставив код sql в чистоте)?

Не будет ли это через чур параноидальным шагом?

Хотелось просто какое-то более изящное решение, чтобы всё это можно было контролировать с одного места.

_____________
"О наших провалах знает весь мир, о наших победах не знает никто." ЦРУ

chapaev
На JS - это красота для клиента, то есть красивый интерфейс.
На PHP - основная проверка.
___________________________
У тебя База находится в Mysql? Как ты собираешься проверить на JS ?

_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).

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

_____________
Блог | VK | GitHub | Twitch

inpost

chapaev
JS валидация - это плюшки сверху. Чтобы сделать сайт более привлекательным и удобным. Всё

_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).

AlmazDelDiablo

Приблизительно это я и хотел услышать.

inpost

twin
А я уж было думал, что все единогласно за одно мнение. Уважаемый twin, можно подробнее?
Вы противник "тонких клиентов" и "раздутой серверной части"?

А как же кулхацкеры? Ведь серверная часть доступна не только для вашего сайта (в данном контексте - визуальщина, фронт-энд и тд) с функционалом JS, но и для обычных POST/GET запросов, которые формируй, как хочешь, вставляй, что хочешь.

Отправил переполненное значение какого-то параметра - получил проблему в работе базы, рухнули триггеры-обзоры-пакеты и тд, получил SQL-иньекцию. Оставив все проверки на JS - падает безопасность бэка.


_____________
"О наших провалах знает весь мир, о наших победах не знает никто." ЦРУ

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

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

twin
Параметров куча.

Например:
- те же данные для авторизации/регистрации
- те же параметры-фильтры на вывод контента по результатам запроса в БД, где введённый параметр в итоге попадёт в скл-запрос. (назовём правильно - связываемые переменные)
- валидации формата даты, передающиеся на бэк-энд часть для всякого рода обработки и тд и тп.
- возможно вообще целые массивы данных в виде хмл, которые на бэке должны десериализироваться в объекты, и тд и тп. (в данном контексте массив - сложная структура, а не [1,2,3,5...], десериализироваться в контексте - сохранённое состояние объекта трансформировать в реальный объект).

Скажем так - это весь поток данных от клиента к серверу.

Да и просто защита от php и sql инкладов/инъекций.

----------------------