Сообщение Re[11]: Зачем нужен ORM? от 01.10.2018 2:38
Изменено 01.10.2018 5:20 Somescout
Re[11]: Зачем нужен ORM?
Здравствуйте, Titus, Вы писали:
T>Валидация ввода идет на трех этапах:
T>1) View — скорее для честных людей.
T>2) Controller — в Model числа отправляет, как числа, а не как строки.
T>3) Model — валидирует и при необходимости преобразует строки на предмет исключения причин заваливания запроса и инъекций.
T>В принципе, если клоунадой заниматься не собираешься, можем проверить устойчивость такого подхода на конкретных примерах.
И ещё раз: использование параметризованных запросов — это абсолютно базовая практика безопасности для защиты от sql-иньекций. Вы предлагаете (зачем-то) делать всё что угодно, кроме этого.
А насчёт "устойчивости такого подхода": что надёжнее — доверить драйверу базы данных обеспечивать безопасность использования данных, или пытаться это делать самому? Учитывая что особенности экранирования значений могут быть специфичны для баз данных? (И учитывая что вы сами говорите о "низкой квалификации разработчиков")
T>Валидация ввода идет на трех этапах:
T>1) View — скорее для честных людей.
T>2) Controller — в Model числа отправляет, как числа, а не как строки.
T>3) Model — валидирует и при необходимости преобразует строки на предмет исключения причин заваливания запроса и инъекций.
T>В принципе, если клоунадой заниматься не собираешься, можем проверить устойчивость такого подхода на конкретных примерах.
И ещё раз: использование параметризованных запросов — это абсолютно базовая практика безопасности для защиты от sql-иньекций. Вы предлагаете (зачем-то) делать всё что угодно, кроме этого.
А насчёт "устойчивости такого подхода": что надёжнее — доверить драйверу базы данных обеспечивать безопасность использования данных, или пытаться это делать самому? Учитывая что особенности экранирования значений могут быть специфичны для баз данных? (И учитывая что вы сами говорите о "низкой квалификации разработчиков")
Re[11]: Зачем нужен ORM?
Здравствуйте, Titus, Вы писали:
T>Валидация ввода идет на трех этапах:
T>1) View — скорее для честных людей.
T>2) Controller — в Model числа отправляет, как числа, а не как строки.
T>3) Model — валидирует и при необходимости преобразует строки на предмет исключения причин заваливания запроса и инъекций.
T>В принципе, если клоунадой заниматься не собираешься, можем проверить устойчивость такого подхода на конкретных примерах.
И ещё раз: использование параметризованных запросов — это абсолютно базовая практика безопасности для защиты от sql-иньекций. Вы предлагаете (зачем-то) делать всё что угодно, кроме этого.
А насчёт "устойчивости такого подхода": что надёжнее — доверить драйверу базы данных обеспечивать безопасность использования данных, или пытаться это делать самому? Учитывая что особенности экранирования значениймогут быть специфичны для баз данных? (И учитывая что вы сами говорите о "низкой квалификации разработчиков")
T>Валидация ввода идет на трех этапах:
T>1) View — скорее для честных людей.
T>2) Controller — в Model числа отправляет, как числа, а не как строки.
T>3) Model — валидирует и при необходимости преобразует строки на предмет исключения причин заваливания запроса и инъекций.
T>В принципе, если клоунадой заниматься не собираешься, можем проверить устойчивость такого подхода на конкретных примерах.
И ещё раз: использование параметризованных запросов — это абсолютно базовая практика безопасности для защиты от sql-иньекций. Вы предлагаете (зачем-то) делать всё что угодно, кроме этого.
А насчёт "устойчивости такого подхода": что надёжнее — доверить драйверу базы данных обеспечивать безопасность использования данных, или пытаться это делать самому? Учитывая что особенности экранирования значений