- 1
$result = $db->query("update `" . $table_prefix . "options` set `option_value`='a:2:{i:0;b:0;s:8:" . '"auto_add"' . ";a:0:{}}' where `option_name`='nav_menu_options';");
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+163
$result = $db->query("update `" . $table_prefix . "options` set `option_value`='a:2:{i:0;b:0;s:8:" . '"auto_add"' . ";a:0:{}}' where `option_name`='nav_menu_options';");
unserialize "глазами на лету" - ЛЕГКО!!!!
И только в пыхе не смогли
Пока сам не попробовал использовать prepared statements?
> но склеивать запросы руками не перестанут
К сожалению, не всё можно забиндить.
Cодержимое IN (...), например.
Я в таком случае генерю IN (?, ?, ?, ?) и биндю аргументы.
Как-то так:
немногие субд предлагают хоть что-то для этого, и поэтому работа с коллекциями из какого-нибудь jdbc это тот еще геморрой
А это значит что:
* Базе не надо будет заново каждый раз парсить запрос и строить план: она понимает что если X был 3, а стал 4 то это ТОТ ЖЕ САМЫЙ запрос.
* База может нормально работать с кешем результатов понимая что от изменения одного значения ничего не поменяется
* Даже в случае баги языка SqlInjection невозможен физически.
Таким вот образом становится понятно что в идеальном мире не стоит делать свой препроцессинг.
В реальном же мире иногда обертки просто делают sprintf и эскейп, база про стейтменты ничего не знает, и можно делать какой угодно препроцессинг
Что-то в духе:
Просто в 99% случаев подготовленные запросы юзаются не по назначению - подготовили, исполнили с параметрами и вынесли. Это оверхед и куча лишней писанины, особенно в языках типа сишки, где нельзя просто так взять и передать массив параметров в execute.
А то, что нужно в типичном коде, не вставляющем миллион строк подряд - всего лишь запрос с параметрами.
>> Они будут экранировать, экранировать экранированное,
А потом в базе будет восемь слешек, и все равно SQL Injection, ха-ха-ха