Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
/**
* Compile Bindings
*
* @access public
* @param string the sql statement
* @param array an array of bind data
* @return string
*/
function compile_binds($sql, $binds)
{
if (strpos($sql, $this->bind_marker) === FALSE)
{
return $sql;
}
if ( ! is_array($binds))
{
$binds = array($binds);
}
// Get the sql segments around the bind markers
$segments = explode($this->bind_marker, $sql);
// The count of bind should be 1 less then the count of segments
// If there are more bind arguments trim it down
if (count($binds) >= count($segments)) {
$binds = array_slice($binds, 0, count($segments)-1);
}
// Construct the binded query
$result = $segments[0];
$i = 0;
foreach ($binds as $bind)
{
$result .= $this->escape($bind);
$result .= $segments[++$i];
}
return $result;
}
Ковыряю легаси.
Кодигнайтер первый.
Типа биндинг параметров в SQL запросе (вне зависимости от драйвера бд).
Полез я позырить с какого хера оно не ругается на не равное кол-во переданных параметров и плейсхолдеров к ним, т.к. просто забыл дописать в запрос WHERE id = ? при живом переданном айдишнике.
Биндинг параметров подразумевает "РАЗДЕЛЬНУЮ" отправку на сервер БД текста запроса с плейсхолдерами и самих даных. В бинарном виде, клиентский запрос, пропущенный через биндинг параметров (prepared statement) выглядит примерно так:
<текст запроса с плейсхолдерами><данные1><данные2><данные N>
Такой подход реально защищает от SQL-инъекций, т.к. данные находятся не в тексте запроса.
Вышеприведенный же говнокод разбивает строку запроса по плейсхолдеру на массив и джойнит этот массив обратно, попутно заменяя плейсхолдеры тупым, потенциально дырявым эскейпингом. В итоге, запрос на сервер отправляется по старинке, тупо текстом.
Кроме того, по коду видно, что, если я не поставил плейсхолдер, но воткнул данные для бинда, то мои данные будут проигнорированы, если я передал больше параметров, лишние будут проигнорированы, если я передал больше плейсхолдеров, обратно в строку соберется не весь текст запроса, и будет синтаксически не верным, а ошибкой ответит сам сервер, а не драйвер.
Биндинг параметров подразумевает "РАЗДЕЛЬНУЮ" отправку на сервер БД текста запроса с плейсхолдерами и самих даных. В бинарном виде, клиентский запрос, пропущенный через биндинг параметров (prepared statement) выглядит примерно так:
<текст запроса с плейсхолдерами><данные1><данные2><данные N>
Такой подход реально защищает от SQL-инъекций, т.к. данные находятся не в тексте запроса.
Вышеприведенный же говнокод разбивает строку запроса по плейсхолдеру на массив и джойнит этот массив обратно, попутно заменяя плейсхолдеры тупым, потенциально дырявым эскейпингом. В итоге, запрос на сервер отправляется по старинке, тупо текстом.
Кроме того, по коду видно, что, если я не поставил плейсхолдер, но воткнул данные для бинда, то мои данные будут проигнорированы, если я передал больше параметров, лишние будут проигнорированы, если я передал больше плейсхолдеров, обратно в строку соберется не весь текст запроса, и будет синтаксически не верным, а ошибкой ответит сам сервер, а не драйвер.