не работает, пробовал по разному:


в других классах примерно так формируется:


кстате никто не видел идеальный поисковик? на cpan много модулей, может быть там есть, найти сложновато

Это сообщение отредактировал(а) gcc - 4.1.2009, 16:33

Офф топ!
Что значит 'экранировать' ? Это что то вроде сделать интерфейс для удобного вызова?

не экранировать, но если поставить так 



 не работает... сделал так:




Добавлено @ 20:20

да, именно для удобства и экономии кода (если что-то захочется изменить, то чтобы не переписывать несколько раз одно и тоже)

Это сообщение отредактировал(а) gcc - 5.1.2009, 12:31

Добавлено через 1 минуту и 16 секунд
но лучше продумать код... 
$self->{SQL}->{LIKE} вдруг с ошибкой будет... ;)

А, сделать так:

вроде оно?    

и так  Способов много, это ж Perl.
gcc, что скажите?

я пометил что решил давно

пользуюсь случаем:

если не использовать prepare, а экранирвоать qq() и использовать через do selectall_*  selectrow_* инъекции не будет?

qq()  эскепит кавычки от инъекции?




Это сообщение отредактировал(а) gcc - 9.1.2009, 16:57

gcc, а зачем спрашивать  ? Можно ведь самому увидеть вывод qq() или сами запросы.
Так даже бывает интереснее, попытаться самому проверить.

Шуранов, боюсь, предложенный Вами вариант будет работать только в случае, если сервер не поддерживает placeholders (когда подстановка значений происходит в модуле DBI), иначе запрос не пройдет синтаксический контроль.

ginnie,  я все время использую так через prepare и $sth->execute('bind')

DBI,  DBD::MySQl должны стоять всегда,  (или в чем проблема эти модули поставить... ?)

Добавлено через 8 минут и 17 секунд
nitr, 

я нашел:


http://www.easysoft.com/developer/language...ial_part_2.html

тогда значит qq() не достаточно

проверить на 100 я не смогу потомучто регулярные выражения perl не полностью знаю...

Это сообщение отредактировал(а) gcc - 11.1.2009, 20:31

ginnie, А как тогда использовать по другому через  quote()?

gcc, верно начинаете думать...
можно открыть кукбук, там про экранирование строк есть (где про БД), и как раз ваш вопрос с qq{} есть ;).

Добавлено через 1 минуту и 10 секунд
ginnie, ваш ответ я не понял, т.е. вы меня запутали  .

Добавлено через 9 минут и 16 секунд
gcc, в вашем модуле можно продумать метод, сразу извиняюсь за название, надеюсь придумает, а я передам идею ;).

будем считать у вас свой dbh возвращается $self->{dbh}, или подобие такой функции (она только подобие  ).


Вот наш метод (тоже не совершенство):

nitr, приношу извинения за сумбурное изложение мыслей   

СУБД может поддерживать prepared statements, а может не поддерживать (для MySQL см. Prepared statement support (server side prepare)). Если СУБД их поддерживает, то запросы с placeholders проходят синтаксический контроль на стороне сервера и вариант



его не пройдет. Если сервер не поддерживает prepared statements, то подстановка значений осуществляется модулем DBI (без синтаксического контроля), при этом указанный вариант может сработать (не проверял).

ginnie, не много не понял,  если не будет включено mysql_server_prepare=1, то экранироватся через execute() не будет? 



у меня везде MySQL 5.0, а как точно проверить работает ли синтаксический контроль? 

Это сообщение отредактировал(а) gcc - 12.1.2009, 18:36

gcc, экранироваться будет в любом случае. Не всегда будет работать prepared statement (используется для ускорения выполнения запросов).

Добавлено @ 18:56
По поводу проверки, попробуйте включить trace в DBI и выполнить запрос с placeholder'ами, посмотрите что передается в СУБД.
Кроме того, попробуйте указанный выше вариант (замените названия таблицы и поля на свои)



и приведите здесь сообщение об ошибке.

P.S. Посмотрел сейчас код и понял, что он даже при непосредственной подстановке в DBI не сработает из-за экранирования.

Это сообщение отредактировал(а) ginnie - 12.1.2009, 19:02

trace я не включал, не знаю как его включит, надо посмотреть, попробовать

я написал так:

ничего не вывел


скорость мне не нужна, ну вот такой запрос прошел и вывел:




Это сообщение отредактировал(а) gcc - 12.1.2009, 19:58

написал программу, сейчас смотрю что оптимизирвать можно и парадигму ООП по красивей пересматриваю...

появился вопрос про DBI, было написано в статье что что метод do быстрее, есть ли разнциы по скорости между метода do или prepare? никто не тестировал?

или можно использовать исключительно prepare? (передаються int числовые значения, инъекций не будет)

если do быстрее, то как написать для HTML::Template массив хєшей?



так не работает:


тут только arrayref подходит и названия столбцов через цыклы пропустить? но это не удобно...

Это сообщение отредактировал(а) gcc - 10.4.2009, 04:36

Врядли do быстрее. Потому что в нутри do есть prepare

tolkien,  врядли там есть prepare. do метод сделали как раз чтобы выполнять действия без вывода ошибочной информации, там только 0 или 1 и в нем нету защиты от инъекций...

gcc, плохо читали документацию.

хотел спросить на всякий случай:



это регулярное выражение /^\d+$/ защетит от инъекция? дырки в каталисте точно не будет, или абсолютно всё нужно ставить в execute();? (у меня много int значений)

товарищи, я хотел спросить, это регулярное выражение /^\d+$/ защетит от инъекция?