- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Что делать, если ваша email-рассылка попала в спам
10 распространенных причин и решений
Екатерина Ткаченко
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Решил перевести все свои "творения" под PDO. Но, как и при прямом MySQL у меня, прямо как Гондурас, чесался и чешется вопрос про экранирование всяческой фигни.
Почитал поиск, сравнил/потестил несколько PDO-реализаций (CI, ezSQL), потестил "quote". И ничего не вкурил. Т.к. кое-где (отдельные классы) string даже через filter прогоняют.
Если mysql_real_escape_string слэшил кучку неприятных символов, то quote никак это не делает (а может в этом и фишка функции и/или PDO?). Сейчас посмотрю в сторону "SET SQL_MODE=ANSI_QUOTES", но боюсь не на всех хостингах будет возможность включить.
Вопрос.
Может кто в пару-тройку слов объяснить как правильно в PDO-MySQL слэшить то, что делала функция mysql_real_escape_string?
Или забить и "верить" :) quote?
Или как это правильно делать?
Также буду признателен за ссылочку на реализацию Yii/Zend под PDO-MySQL (на эти классы посмотреть бы - все качать пока не пойму - нет смысла, если полностью их не пользовать). Или сюда кусочки кода.
Вроде бы для этого надо юзать prepare()
Возможно. И что это решит?
Скажем на HTML (переведу к едрене м. все на markdown) можно натравить kses, safehtml, htmlpurifer.
Голое текстовое поле или текстареа понапихать можно всякого.
Можно и на такое filter_var, например, накинуть. Да и по старинке sprintf написать.
Но вот глянуть классы валидации/санитизации от Drupal, WP, Contao, TYPO3 до фреймворков всяких - они чем занимаются? Было бы все так просто.
Кстати, мануал был давно и полностью прочитан. Тамошние комменты также. Убогие они. У них там практически бодаются с селектами. А славянские парни горазды что-то в инсерт всадить :) дополнительно, так сказать, в нагрузку. И чтобы веб-мастер свистнул, как та японская пила.
Правильно делать это так,
$query = $db->prepare('
SELECT *
FROM :nameoftable
;');
$query->execute([ ':nameoftable' => 'table'
]);
где, :nameoftable - входящий параметр, а его значение передается в массиве при вызове execute();
PDO:prepare решит то, что входящие данные будут фигурировать в SQL запросе, как входящие данные, а не составная запроса. PDO:prepare гарантирует только это, но не валидность входящих данных. Входящие данные нужно проверять отдельно от SQL запроса. И если в проверку входит экранирование специальных символов, и используется только одна СУБД, плюсов от использования PDO, я не вижу, а минусы есть - производительность и синтаксис.
Для новых проектов на MySQL, PHP рекомендует использовать MySQLi класс.
Возможно. И что это решит?
решит всё, что нужно.
защита от инъекций предоставляется.
валидация данных - дело юзера и конкретной задачи.
Кстати, мануал был давно и полностью прочитан.
не верю. иначе вы бы получили ответ на свой вопрос:
Если вы используете эту функцию для построения SQL запросов, настоятельно рекомендуется пользоваться методом PDO::prepare() для подготовки запроса с псевдопеременными вместо использования PDO::quote()
Спасибочки всем.
Буду думать быстро.