Класс для безопасной работы с MySQL

Фанат

oncle terrible
Команда форума
Удивительно, но похоже, все проблемы мы решили?
- с множественным подключением: кому надо-пусть пишет свою регистри-шмегистри, кому не надо - сделает два инстанса для двух датабаз, и будет подключать их через жлобал.
- с парсингом паршеного: с помощью нового плейсхолдера. Который, заодно, убирает противоречие в описании класса. Если раньше нельзя было сказать "любые динамические элементы подставляются в запрос только через плейсхолдеры", то теперь - можно!
Единственный недостаток этого плейсхолдера - в отличие от всех остальных он пропускает ошибки синтаксиса. Это единственный компромисс с безопасностью.
- с тупыми ошибками двойного парсинга и array_search (алгоритм которого, кстати, поменялся)

Больше принципиальных проблем, вроде бы, не выявлено?
 

~WR~

Новичок
Посмотрел еще разок. Заметил потенциальную проблему с utf-8.

Сейчас везде используются функции для single-byte кодировок.
В большинстве случаев это не создаст проблем, т.к. криво выбранные позиции из PREG_OFFSET_CAPTURE потом передаются substr_replace и strlen, которые так же криво посчитают offset и shift. Но в итоге результат получается правильный, т.к. система координат у них одна и та же.

Но есть такая интересная штука, как mbstring function overloading: http://php.net/manual/en/mbstring.overload.php
Если она включена, то strlen внезапно начнет считать длину utf-8 строки правильно. И тогда shift разойдется с offset'ом, полученным из preg_match_all.

Думаю, если хорошенько заморочиться, то можно будет сделать sql-инъекцию, грамотно затерев соседние кавычки.
Не проверял. Просто абстрактная идея.
 

Вурдалак

Продвинутый новичок
mbstring.func_overload — очередной гребаный костыль PHP. Людей, которые такое пихают в язык, надо убивать. Повесить рядом с теми, кто в своё время добавил magic_quotes и register_globals.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
однако же mbstring.func_overload включен на очень многих серверах!
нельзя просто сказать, что 30% программеров идиоты и у них класс работать не будет просто потому что на их сервере включена эта опция
 

Вурдалак

Продвинутый новичок
Откуда статистика про 30%? А как эти несчастные живут с отсутствием нормальной возможности работать с бинарными данными?

А проблема надумана — написать скрипт конвертёр с обычных на mb_*-функции — 5 минут работы.
 

~WR~

Новичок
Я бы добавил флаг 'u' в регулярку, заменил функции на mb_* аналоги и добавил в конструкторе проверку на само наличие mbstring.
Это наиболее правильный вариант.

Afaik, все более-менее современные фреймворки и движки обязательно требуют mbstring.
По той причине, что работа с utf-8 без него - игры с огнем и с неизвестным результатом.

Жаль, что разработчики php забили шествую версию и на поддержку utf-8 в ядре.
 

~WR~

Новичок
Откуда статистика про 30%?
По моему опыту - больше чем в половине случаев оно включено, особенно если код начали писать несколько лет назад.
Как правило, выключено в случае с фреймворками или с очень новым кодом. Либо авторы просто еще не столкнулись с тем, что они накосячили.

Простая замена не покатит, т.к. не для всех функций есть mb_* аналоги. Яркий пример - substr_replace. mb_substr_replace не существует в природе.
 

Вурдалак

Продвинутый новичок
Простая замена не покатит, т.к. не для всех функций есть mb_* аналоги. Яркий пример - substr_replace. mb_substr_replace не существует в природе.
http://php.net/manual/en/mbstring.overload.php
Там приведён, насколько я понимаю, точный список того что будет на что заменяться. Получается, substr_replace() будет работать как и прежде — бинарно, так?

И я так и не понял как эти несчастные работают с бинарными данными. Какой-то парсер файла в бинарном формате зачастую где-то требует обрезать несколько байт и т.п. — переписывают код?
 

Вурдалак

Продвинутый новичок
А вообще да, я считаю, что осуществлять поддержку таких костылей для нового кода даже вредно. Программисты вполне могут либо выделить отдельный инстанс php-fpm для старых скриптов, либо переписать код.
 

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
И я так и не понял как эти несчастные работают с бинарными данными.
PHP:
mb_internal_encoding('8bit');
Хотя количество граблей, заботливо разложенных авторами похапе в похапе.ини радует, да.
 

Фанат

oncle terrible
Команда форума
Я бы добавил флаг 'u' в регулярку, заменил функции на mb_* аналоги и добавил в конструкторе проверку на само наличие mbstring.
Я ещё чуть-чуть похалявить попытаюсь, можно?
Классическое
PHP:
$oldenc = mb_internal_encoding('8bit');
mb_internal_encoding('8bit');
//строчим
mb_internal_encoding($oldenc);
- это совсем говнокод?
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
А вообще да, я считаю, что осуществлять поддержку таких костылей для нового кода даже вредно. Программисты вполне могут либо выделить отдельный инстанс php-fpm для старых скриптов, либо переписать код.
ИМХО это их интимные проблемы уже.
как эти несчастные работают с бинарными данными
отлично, что мы классные и хорошо знаем как надо,
а теперь оставим ЧСВ в стороне и вспомним цель написания этой библиотеки -
вспомним про ее будущих пользователей, их задачи, и забудем про fpm, выделенные серверы и бинарные данные

По моему опыту - больше чем в половине случаев оно включено
в англоязычном инете меньше, в рунете - на большинстве хостингов
 

Фанат

oncle terrible
Команда форума
Англоязычный меня интересует не меньше :)
PHP:
В принципе, функций в коде мало, меня не заломает переопределить их, типа 
if ($this->mbstring) {
    $strlen = "mb_strlen";
}
$strlen($value);
вообще, раз такие сложности, можно ведь поменять алгоритм. Использовать, к примеру, прег сплит, и собирать из кусочков.

Во. Вечером попробую. Уж очень не хочется связываться с этими строками.
 

fixxxer

К.О.
Партнер клуба
если включен mbstring overload то оригинальные функции не удаляются, а переименовываются с префиксом orig_.
можно использовать этот факт
 

Фанат

oncle terrible
Команда форума
если включен mbstring overload то оригинальные функции не удаляются, а переименовываются с префиксом orig_.
можно использовать этот факт
круть! отличная идея!

Но я попробую сначала, всё-таки, вообще без строковых, одним рыгом. Вроде бы, склеить из массива должно получиться без проблем.
Учитывая, что при текущем раскладе парсится только запрос, но не данные, то проблем быть не должно.
 

Absinthe

жожо
я считаю, что осуществлять поддержку таких костылей для нового кода даже вредно
+1.

а теперь оставим ЧСВ в стороне и вспомним цель написания этой библиотеки
Итак, какая же цель? Облегчение говнокодинга? Или его устранение?
 
Сверху