>Теперь разберёмся с замечаниями, которые вы нашли по моей ссылке.
и
>вы что-то на пруфы не расщедрились
Так ссылка-то Ваша… :)
Кстати, там же:
>Например, вы не можете привязать несколько значений к одному параметру для SQL выражения IN().
То есть для каждого value в IN(value1, ..., valueN) или заводить свой именованный параметр, или не использовать подготовленные выражения :)
Если заводить свой именованный параметр, то повторное использование заканает, если будет одинаковое число параметров.
>Теперь по поводу того, зачем выполнять один запрос несколько раз, если можно сделать column in.
В разных местах обычно нужно выбрать разные данные, * вибирать не совсем правильно. :)
И еще раз поищите и подумайте, что делают эмулированные, которые по умолчанию. Там нет никакого плана запроса, просто данные искейпятся. Сделано это для поддержки старых серверов, которые не имеют серверных подготовленных выражений.
Цитата касается подготовленных запросов на сервере.
Поищите как работают эмулированные.
По поводу повторных запросов.
Это работает только с подготовленными выражениями на сервере.
В случае одинарных запросов производительность просядает, поэтому и используется по умолчанию эмуляция.
Также я не особо понимаю смысла однотипных запросов, если можно выполнить один запрос с WHERE `column` IN (val1, ..., valN).
По Вашей ссылке также:
>Замечание:
>Эмулируемые подготовленные запросы не создаются на сервере баз данных, поэтому PDO::prepare() не может проверить правильность построенного запроса.
Сырое.
Нету JOINов.
Вместо self::$db->query(«SET NAMES '$enc'»); лучше mysqli_set_charset($link, $enc);
И, наверное, не стоит жестко завязываться на mysqli, как и на любой другой.
Зачем $id = key(self::_getVars()); в Save(), Remove()?
Да и вообще ORM — фигня.
Смысл прописывать поля, которые есть у таблицы?
Также у Вас не пройдет частичное обновление записей, также можно обновить только по первичному ключу.
>if (isset($mValue[0]) && !empty($mValue[0]))
Достаточно !empty($mValue[0]
Также отступы слева во всех примерах кода стоило бы уменьшить.
Ага, у голосового меню тоже лимит на переключение на оператора.
Сегодня звонил, предложения нажать 9 для соединения с оператором не было.
А раньше у КС был лучший КЦ.
Дали 3 мес интернета?
Это такое.
Вы им хоть пользовались ранее?
Буду знать, что уязвимости в КС не стоить репортить.
Кстати, находя уязвимость/баг у банка всегда спрашиваю есть ли у них программа благодарствий за это.
Ни у одного банка еще не было. :) Ну я им и не открывал тайну. Хотя 1 раз сказал, что стоило бы добавить переадресацию с http на https в ИБ Альфабанку. Но прошло уже несколко лет, а воз и ныне там.
Писал тут статью о дырах Дельтабанка, ее не пропустили, хз чего, банк-то уже был в стадии ликвидации, ИБ там не работал.
Нашел дыру у хостинга. Дали год хостинга. Дыру не исправили. :)
У нас в компании легко достучаться по проблеме веба. Один клиент даже генеральному недавно пожаловался, что его баг долго фиксили. :) Некоторые баги дейтсвительно не воспроизводятся, а иногда КЦ/ТП передают разработчикам некорректную информацию :)
>автоэкранирование в шаблонах по сути своей намного ближе к emulated prepares в pdo.
С чего бы?
Подготовленные выражения работают явно.
Мы вызываем функционал, который будет экранировать.
Да и htmlspecialchars не экранирует…
htmlspecialchars преобразует специальные символы в HTML-сущности.
«Автоэкранирование» не панацея.
А иногда оно лишнее.
Например нужно вывести строку, где должен быть кусок html, а остальные данные с базы.
Если понядеятся на «автоэкранирование», то html выведется испорченный.
Если отключить «автоэкранирование», то с базы может пролезть html.
Экранировать нужно вручную то, что нужно.
Если используется кеширование, то заэкранировать лучше один раз и сохранить в кеш.
Я шаблоны вообще не кеширую, кеширую только «контроллеры».
Часто в базе хранится уже обработанный html, или про-htmlspecialchars-енный, или про-strip_tags-енный. Повторная обработка испортит его.
А так да, для клепания говносайтов низкоквалифицированными разработчиками автоэкранирование нужно. :)
>Знаю такую страницу, только не понимаю к чему это?
Почему это все подключается…
В том файле не только БД ну и остальное.
>Нет они пишутся в файл '/urlrewrite.php' (не путать с 'bitrix/urlrewrite.php' который отвечает за маршрутизацию), не вижу смысла подключать его, если в дальнейшем (если нет подходящих правил) все равно маршрутизацией будет заниматься битирксовый роутер
Боже, роуты пишутся вручную или с редактора параметров компонента?
Я с Битриксом 2 года не работаю уже, поэтому могу ошибаться, поэтому вроде. :)
>В основном там база.
Вчера искал исходник с работы по Битриксу, ради интереса залез в дбконн, там много всего, короме базы. Для базы вроде только адресс сервера, логин, пароль, база.
Все это потом будет оплачивать заказчик. :)
При пулл-реквесте в любом случае нужно просматривать код, пофиг кто его писал.
и
>вы что-то на пруфы не расщедрились
Так ссылка-то Ваша… :)
Кстати, там же:
>Например, вы не можете привязать несколько значений к одному параметру для SQL выражения IN().
То есть для каждого value в IN(value1, ..., valueN) или заводить свой именованный параметр, или не использовать подготовленные выражения :)
Если заводить свой именованный параметр, то повторное использование заканает, если будет одинаковое число параметров.
>Теперь по поводу того, зачем выполнять один запрос несколько раз, если можно сделать column in.
В разных местах обычно нужно выбрать разные данные, * вибирать не совсем правильно. :)
И еще раз поищите и подумайте, что делают эмулированные, которые по умолчанию. Там нет никакого плана запроса, просто данные искейпятся. Сделано это для поддержки старых серверов, которые не имеют серверных подготовленных выражений.
http://stackoverflow.com/questions/15718148/php-prepared-statements-turn-emulation-off (первый ответ)
https://forum.phalconphp.com/discussion/9183/are-rawsql-prepared-statements-emulated-or-for-real
Поищите как работают эмулированные.
По поводу повторных запросов.
Это работает только с подготовленными выражениями на сервере.
В случае одинарных запросов производительность просядает, поэтому и используется по умолчанию эмуляция.
Также я не особо понимаю смысла однотипных запросов, если можно выполнить один запрос с WHERE `column` IN (val1, ..., valN).
По Вашей ссылке также:
>Замечание:
>Эмулируемые подготовленные запросы не создаются на сервере баз данных, поэтому PDO::prepare() не может проверить правильность построенного запроса.
Нету JOINов.
Вместо self::$db->query(«SET NAMES '$enc'»); лучше mysqli_set_charset($link, $enc);
И, наверное, не стоит жестко завязываться на mysqli, как и на любой другой.
Зачем $id = key(self::_getVars()); в Save(), Remove()?
Да и вообще ORM — фигня.
Смысл прописывать поля, которые есть у таблицы?
Также у Вас не пройдет частичное обновление записей, также можно обновить только по первичному ключу.
>if (isset($mValue[0]) && !empty($mValue[0]))
Достаточно !empty($mValue[0]
Также отступы слева во всех примерах кода стоило бы уменьшить.
Ну такое.
Сегодня звонил, предложения нажать 9 для соединения с оператором не было.
А раньше у КС был лучший КЦ.
Это такое.
Вы им хоть пользовались ранее?
Буду знать, что уязвимости в КС не стоить репортить.
Кстати, находя уязвимость/баг у банка всегда спрашиваю есть ли у них программа благодарствий за это.
Ни у одного банка еще не было. :) Ну я им и не открывал тайну. Хотя 1 раз сказал, что стоило бы добавить переадресацию с http на https в ИБ Альфабанку. Но прошло уже несколко лет, а воз и ныне там.
Писал тут статью о дырах Дельтабанка, ее не пропустили, хз чего, банк-то уже был в стадии ликвидации, ИБ там не работал.
Нашел дыру у хостинга. Дали год хостинга. Дыру не исправили. :)
У нас в компании легко достучаться по проблеме веба. Один клиент даже генеральному недавно пожаловался, что его баг долго фиксили. :) Некоторые баги дейтсвительно не воспроизводятся, а иногда КЦ/ТП передают разработчикам некорректную информацию :)
У меня до техдира 3 начальника есть. :)
С чего бы?
Подготовленные выражения работают явно.
Мы вызываем функционал, который будет экранировать.
Да и htmlspecialchars не экранирует…
htmlspecialchars преобразует специальные символы в HTML-сущности.
«Автоэкранирование» не панацея.
А иногда оно лишнее.
Например нужно вывести строку, где должен быть кусок html, а остальные данные с базы.
Если понядеятся на «автоэкранирование», то html выведется испорченный.
Если отключить «автоэкранирование», то с базы может пролезть html.
Экранировать нужно вручную то, что нужно.
Если используется кеширование, то заэкранировать лучше один раз и сохранить в кеш.
Я шаблоны вообще не кеширую, кеширую только «контроллеры».
Часто в базе хранится уже обработанный html, или про-htmlspecialchars-енный, или про-strip_tags-енный. Повторная обработка испортит его.
А так да, для клепания говносайтов низкоквалифицированными разработчиками автоэкранирование нужно. :)
Я знаю, что у битрикса свой формат.
Я спрашиваю, пишете ли вы в свой файл. :)
http://php.net/security.magicquotes
Или register_globals
Раньше все дрочили на это.
Сейчас все проклинают.
Автоэкранирование не панацея от XSS.
Все это нужно для низкоквалифицированных разработчиков.
И конфликты пакетов с mysql
Там что код-ревью в банках не проводят или там работают одни хакеры?
Решето.
Позор, что их до сих пор не было.
Почему это все подключается…
В том файле не только БД ну и остальное.
>Нет они пишутся в файл '/urlrewrite.php' (не путать с 'bitrix/urlrewrite.php' который отвечает за маршрутизацию), не вижу смысла подключать его, если в дальнейшем (если нет подходящих правил) все равно маршрутизацией будет заниматься битирксовый роутер
Боже, роуты пишутся вручную или с редактора параметров компонента?
Я с Битриксом 2 года не работаю уже, поэтому могу ошибаться, поэтому вроде. :)
>В основном там база.
Вчера искал исходник с работы по Битриксу, ради интереса залез в дбконн, там много всего, короме базы. Для базы вроде только адресс сервера, логин, пароль, база.
>да и из названия это следует
Название неочевидное… :)
>это не должно подключаться до роутинга
http://dev.1c-bitrix.ru/api_help/main/general/pageplan.php
>Если в роутере не сработало ни одно из правил, то далее уже подключается стандартный роутинг
А в конфиг вашего роутинга пишутся параметры с вызуального редактирования параметров комплексного компонента?
Там же вроде не camelCase…
>include dbconn.php
Там вроде не только база, а и другие настройки…
Ваш роутер подтягивает битриксовские правила роутинга?
>Что все эти люди делают с этой простейшей концепцией? Зачем? Ради чего вы вообще пишете вот такой код?
А я вообще не пишу код роутинга, он в нгинксе. :)
эмейлы тоже могут выводится из обращения :)
По теме.
Это не уязвимость ВК, это глупость создателей группы.