Сегодня в официальной документации PHP появилась новая фича: почти любой пример кода можно выполнить и сразу посмотреть результат.
FanatPHP @FanatPHP
User
Герой нашего времени
3 min
Case
На Хабре есть такая штука, как рейтинг авторов. Ну то есть формально это рейтинг пользователей, но в реальности вряд ли в него сможет попасть даже супер-активный читатель. Так что остаются только авторы.
В списке много прославленных имён, но нас сейчас интересует самое первое. Чемпион Хабра. Тот автор, чьи работы посетители сочли самыми интересными, самыми полезными, самыми результативными. Я предлагаю познакомиться с ним поближе. К сожалению, мы не так много знаем о нём. Даже реального фото у меня нет, так что пришлось немного пофантазировать вместе с нейросетью Кандинский.
Действительно ли генераторы помогают экономить память?
6 min
Translation
Недавно я обратил внимание на одно заблуждение, связанное с генераторами, а точнее — с тем, как они позволяют экономить память. Такое ощущение, что многие воспринимают генераторы как инструмент, который позволит им получить "большой прирост производительности" из ничего. Или за такую шляпу фокусника, в которую можно засунуть бесконечное количество данных и не тратить память в самом скрипте.
Сначала я удивился — откуда взялись такие идеи? Ведь мы много лет работали с большими объемами данных без всяких генераторов. Лучшая статья про генераторы в РНР, опубликованная ещё десять лет назад, Что генераторы могут для вас сделать Антонио Феррары тоже практически не упоминает экономию памяти. У меня и у самого всегда было чёткое ощущение, что хотя генераторы — это совершенно отличное изобретение, у которого есть множество разнообразных применений, но вот только экономии памяти среди них нет.
В итоге у меня разыгралось любопытство и я решил разобраться с этим вопросом.
О проблемах информационной безопасности и IT образования на примере HTML Academy
17 min
Меня всегда очень интересовала довольно грустная ситуация с языком РНР. Из неказистого шаблонного движка для веб-страничек, к середине 2010-х он вырос в мощный, современный и аккуратный язык программирования… в то время как практически все обучающие материалы в сети выставляют его всё тем же неуклюжим уродцем, который с огромным трудом, не соблюдая никаких стандартов, позволяет разве что сделать примитивную веб-страничку с кучей уязвимостей. Что, разумеется, уже давно совершенно не так. Поэтому когда на форуме РНР клуба появился пост о наборе "наставников" на курс по РНР в HTML Academy, я не раздумывая подал заявку. Чтобы посмотреть как с обстоит с этим дело на платных курсах, а так же по возможности поделиться своим опытом в этой области.
Что вам сказать? "Если хотите, чтобы вам и дальше нравилась колбаса, не берите экскурсию на мясокомбинат"
Как правильно использовать mysqli
10 min
Translation
Небольшой дисклеймер от переводчика: в РНР сложилась парадоксальная ситуация. Сам язык ушёл далеко вперёд, но изучают его по жутко устаревшим материалам. Собственно, постоянный кринж от кода на Тостере (как в вопросах, так и в ответах) и побудил к переводу данной статьи.
Кроме того, переводчик, также как и вы, считает, что PDO является более продвинутым API для работы с БД, чем mysqli. Но поскольку новички в подавляющем большинстве всё равно начинают с mysqli, то нужен хотя бы один нормальный материал по этому расширению. Не можешь противостоять — возглавь!
Не говоря уже о том, что в последнее время mysqli была сильно улучшена, и из совершенно неюзабельной превратилась в довольно сносную библиотеку, в которой из принципиальных отличий от PDO осталось разве что отсутствие именованных плейсхолдеров. Так что даже (особенно) если вы учили РНР 20 лет назад и всё знаете вдоль и поперёк, то всё равно сможете найти для себя что-то новое.
Как работает блогспам — 2 или Прогнило что-то в датском королевстве
2 min
Честно говоря, самому не верится, что я пишу о спаме, который процветает на ключевом вайти ресурсе Рунета.
Ну ладно, первый раз был про англоязычную версию, которую никто не читает. Но когда запаршивел вполне себе посещаемый qna.habr.com - это уже как-то совсем странно. Я понимаю что Хабр Q&A - это не только веб-разработка. Но вот как-то так исторически сложилось, что половина вопросов именно про неё. И уж казалось бы, разработчики веб-сервиса посвященного программированию должны что-то понимать в защите от спама?
В культовом фильме "Ва-банк" есть сцена, где антагонист Крамер говорит главгерою Квинте: "от селедки ухо!", в смысле "я и сам крутой, и ничего у тебя не получится, получишь дырку от бублика (от селедки ухо)". Но в итоге сам остаётся в дураках. Вот администрация Хабра оказывается в роли такого крамера.
Как работает блогспам
2 min
В последнее время в зарубежном интернете распространилось такое явление, как блогспам.
по сути, это обычный SEO-спам, который использует раскрученные онлайн площадки для продвижения.
Чаще всего публикация представляет из себя слабосвязанный и бессмысленный текст, либо сгенерированный искусственно («корчеватель»), либо скомпилированный из нескольких сущеcтвующих источников автором, который не является специалистом в предметной области, а бездумно копирует куски текста, зачастую противоречащие друг другу.
Рассмотрим такую публикацию на примере
Что не так с популярными статьями, рассказывающими что foo быстрее чем bar?
6 min
Review
Translation
Примечание переводчика: я тоже думал, что время статей "Что быстрее — двойные или одинарные кавычки?" прошло еще 10 лет назад. Но вот подобная статья ("What performance tricks actually work") недавно собрала на Реддите относительно большой рейтинг и даже попала в PHP дайджест на Хабре. Соответственно, я решил перевести статью с критическим разбором этих и подобных им "тестов".
Есть множество статей (и даже целых сайтов), посвященных запуску разнообразных тестов, сравнивающих производительность различных синтаксических конструкций, и заявляющих на этом основании что одна быстрее другой.
Главная проблема
Такие тесты являются неверными по многим причинам, начиная с постановки вопроса и заканчивая ошибками реализации. Но что важнее всего — подобные тесты бессмысленны и в то же время вредны.
- Бессмысленны потому, что никакой практической ценности не несут. Ни один реальный проект еще никогда не был ускорен с использованием методов, приводимых в таких статьях. Просто потому, что не различия в синтаксисе имеют значение для производительности, а обработка данных.
- Вредны потому, что они приводят к появлению дичайших суеверий и — что еще хуже — побуждают ничего не подозревающих читателей писать плохой код, думая при этом что "оптимизируют" его.
Этого должно быть достаточно, чтобы закрыть вопрос. Но даже если принять правила игры и притвориться, будто данные "тесты" имеют хоть какой-то смысл, то выяснится, что их результаты сводятся лишь к демонстрации необразованности тестировщика и отсутствия у него всякого опыта.
PHP класс для удобной и безопасной работы с MySQL
9 min
После написания статьи про защиту от инъекций я взялся за написание класса, реализующего изложенные в ней идеи.
А точнее, поскольку ключевой функционал уже использовался в рамках рабочего фремворка, я занялся выделением его в самостоятельный класс. Пользуясь случаем, хочу поблагодарить участников PHPClub-а за помощь в исправлении нескольких критических ошибок и полезные замечания. Ниже я постараюсь описать основные особенности, но сначала небольшой
В двух словах, класс строится вокруг набора функций-хелперов, позволяющих выполнять большинство операций с БД в одну строку, обеспечивая при этом (в отличие от стандартных API) полную защиту от SQL инъекций, реализованную с помощью расширенного набора плейсхолдеров, защищающих любые типы данных, которые могут попадать запрос.
В основу класса положены три базовых принципа:
Остановлюсь чуть подробнее на каждом из пунктов.
А точнее, поскольку ключевой функционал уже использовался в рамках рабочего фремворка, я занялся выделением его в самостоятельный класс. Пользуясь случаем, хочу поблагодарить участников PHPClub-а за помощь в исправлении нескольких критических ошибок и полезные замечания. Ниже я постараюсь описать основные особенности, но сначала небольшой
дисклеймер
Есть несколько способов работы с SQL — можно использовать квери-билдер, можно ORM, можно работать с чистым SQL. Я избрал последний вариант, потому что мне он ближе. Я совсем не считаю первые два плохими. Просто лично мне всегда было тесно в их рамках. Но я ни в коем случае не утверждаю, что мой вариант лучше. Это просто ещё один вариант. Который можно использовать, в том числе, и при написании ORM-а. В любом случае, я считаю, что наличие безопасного способа работать с чистым SQL не может принести какой-либо вред. Но при этом, возможно, поможет последним оставшимся приверженцам использования mysql_* в коде приложения, отказаться, наконец, от этой порочной практики.
В двух словах, класс строится вокруг набора функций-хелперов, позволяющих выполнять большинство операций с БД в одну строку, обеспечивая при этом (в отличие от стандартных API) полную защиту от SQL инъекций, реализованную с помощью расширенного набора плейсхолдеров, защищающих любые типы данных, которые могут попадать запрос.
В основу класса положены три базовых принципа:
- 100% защита от SQL инъекций
- При этом защита очень удобная в применении, делающая код короче, а не длиннее
- Универсальность, портабельность и простота освоения
Остановлюсь чуть подробнее на каждом из пунктов.
Отчёт о попытке получить заявленную эффективность от prepared statements
4 min
Update: из заголовка статьи убрано слово «неудачной». Подробности ниже!
Рассказывая в своей статье о типичных заблуждениях, связанных с защитой от SQL инъекций, среди прочих я отметил тот факт, что серверные подготовленные выражения не работают в PHP по заявленному эффективному сценарию — 1 раз prepare(), потом 1000 раз executе().
Ну, то есть, в теории-то они работают — в пределах одного запуска скрипта. Но много ли вы знаете скриптов (написанных профессиональными программистами), которые выполняют кучу одинаковых запросов? Вот я тоже не знаю. Повторяющихся запросов (каких-нибудь множественных апдейтов) — доли процента, а в массе своей запросы уникальные (в пределах одного скрипта).
Соответственно, для нашего уникального запроса сначала выполняется prepare(), потом — execute(), потом скрипт благополучно умирает, чтобы, запустившись для обработки следующего HTTP запроса, заново выполнять prepare()… Как-то не слишком похоже на оптимизацию. Скорее — наоборот.
Как верно заметили в комментариях, я должен был упомянуть исключения в виде консольных скриптов и демонов, которые долго держат соединение с БД. Однако основная масса PHP скриптов всё же работает на фронтенде, умирая после выполнения пары десятков запросов.
Но неужели нет способа как-то закэшировать подготовленный запрос между запусками?
Рассказывая в своей статье о типичных заблуждениях, связанных с защитой от SQL инъекций, среди прочих я отметил тот факт, что серверные подготовленные выражения не работают в PHP по заявленному эффективному сценарию — 1 раз prepare(), потом 1000 раз executе().
Ну, то есть, в теории-то они работают — в пределах одного запуска скрипта. Но много ли вы знаете скриптов (написанных профессиональными программистами), которые выполняют кучу одинаковых запросов? Вот я тоже не знаю. Повторяющихся запросов (каких-нибудь множественных апдейтов) — доли процента, а в массе своей запросы уникальные (в пределах одного скрипта).
Соответственно, для нашего уникального запроса сначала выполняется prepare(), потом — execute(), потом скрипт благополучно умирает, чтобы, запустившись для обработки следующего HTTP запроса, заново выполнять prepare()… Как-то не слишком похоже на оптимизацию. Скорее — наоборот.
Как верно заметили в комментариях, я должен был упомянуть исключения в виде консольных скриптов и демонов, которые долго держат соединение с БД. Однако основная масса PHP скриптов всё же работает на фронтенде, умирая после выполнения пары десятков запросов.
Но неужели нет способа как-то закэшировать подготовленный запрос между запусками?
Защита от SQL-инъекций в PHP и MySQL
26 min
Recovery Mode
К своему удивлению, я не нашёл на Хабре исчерпывающей статьи на тему защиты от инъекций. Поэтому решил написать свою.
Ещё только начав интересоваться темой защиты от инъекций, я всегда хотел сформулировать набор правил, который был бы одновременно исчерпывающим и компактным. Со временем мне это удалось:
Всего два пункта.
Разумеется, практическая реализация этих правил нуждается в более подробном освещении.
Но у этого списка есть большое достоинство — он точный и исчерпывающий. В отличие от укоренившихся в массовом сознании правил «прогонять пользовательский ввод через mysql_real_escape_string» или «всегда использовать подготовленные выражения», мой набор правил не является катастрофическим заблуждением (как первое) или неполным (как второе).
Но вперёд, читатель — перейдём уже к подробному разбору.
Несколько пространный дисклеймер, не имеющий прямого отношения к вопросу
Давайте признаем факт: количество статей (и комментариев) на тему защиты от SQL-инъекций, появившихся на Хабре в последнее время, говорит нам о том, что поляна далеко не так хорошо истоптана, как полагают некоторые. Причём повторение одних и тех же ошибок наводит на мысль, что некоторые заблуждения слишком устойчивы, и требуется не просто перечисление стандартных техник, а подробное объяснение — как они работают и в каких случаях должны применяться (а в каких — нет).
Статья получилась довольно длинной — в ней собраны результаты исследований за несколько лет — но самую важную информацию я постараюсь компактно изложить в самом начале, а более подробные рассуждения и иллюстрации, а так же различные курьёзы и любопытные факты привести в конце. Также я постараюсь окончательно развеять множественные заблуждения и суеверия, связанные с темой защиты от инъекций.
Я не буду пытаться изображать полиглота и писать рекомендации для всех БД и языков разом. Достаточное количество опыта у меня есть только в веб-разработке, на связке PHP/MySQL. Поэтому все практические примеры и рекомендации будут даваться для этих технологий. Тем не менее, изложенные ниже теоретические принципы применимы, разумеется, для любых других языков и СУБД.
Сразу отвечу на стандартное замечание про ORM, Active record и прочие query builders: во-первых, все эти прекрасные инструменты рождаются не по мановению волшебной палочки из пены морской, а пишутся программистами, используя всё тот же грешный SQL. Во-вторых, будем реалистами: перечисленные технологии — хорошо, но на практике сырой SQL постоянно встречается нам в работе — будь то legacy code или развесистый JOIN, который транслировать в ORM — себе дороже. Так что не будем прятать голову в песок и делать вид, что проблемы нет.
Хоть я и постарался подробно осветить все нюансы, но, вполне возможно, некоторые из моих выводов могут показаться неочевидными. Я вполне допускаю, что мой контекст и контексты читателей могут различаться. И вещи, которые кажутся мне сами собой разумеющимися, не являются таковыми для некоторых читателей. В этом случае буду рад вопросам и уточнениям, которые помогут мне исправить статью, сделав её более понятной и информативной.
Статья получилась довольно длинной — в ней собраны результаты исследований за несколько лет — но самую важную информацию я постараюсь компактно изложить в самом начале, а более подробные рассуждения и иллюстрации, а так же различные курьёзы и любопытные факты привести в конце. Также я постараюсь окончательно развеять множественные заблуждения и суеверия, связанные с темой защиты от инъекций.
Я не буду пытаться изображать полиглота и писать рекомендации для всех БД и языков разом. Достаточное количество опыта у меня есть только в веб-разработке, на связке PHP/MySQL. Поэтому все практические примеры и рекомендации будут даваться для этих технологий. Тем не менее, изложенные ниже теоретические принципы применимы, разумеется, для любых других языков и СУБД.
Сразу отвечу на стандартное замечание про ORM, Active record и прочие query builders: во-первых, все эти прекрасные инструменты рождаются не по мановению волшебной палочки из пены морской, а пишутся программистами, используя всё тот же грешный SQL. Во-вторых, будем реалистами: перечисленные технологии — хорошо, но на практике сырой SQL постоянно встречается нам в работе — будь то legacy code или развесистый JOIN, который транслировать в ORM — себе дороже. Так что не будем прятать голову в песок и делать вид, что проблемы нет.
Хоть я и постарался подробно осветить все нюансы, но, вполне возможно, некоторые из моих выводов могут показаться неочевидными. Я вполне допускаю, что мой контекст и контексты читателей могут различаться. И вещи, которые кажутся мне сами собой разумеющимися, не являются таковыми для некоторых читателей. В этом случае буду рад вопросам и уточнениям, которые помогут мне исправить статью, сделав её более понятной и информативной.
Ещё только начав интересоваться темой защиты от инъекций, я всегда хотел сформулировать набор правил, который был бы одновременно исчерпывающим и компактным. Со временем мне это удалось:
Правила, соблюдение которых гарантирует нас от инъекций
- данные подставляем в запрос только через плейсхолдеры
- идентификаторы и ключевые слова подставляем только из белого списка, прописанного в нашем коде.
Всего два пункта.
Разумеется, практическая реализация этих правил нуждается в более подробном освещении.
Но у этого списка есть большое достоинство — он точный и исчерпывающий. В отличие от укоренившихся в массовом сознании правил «прогонять пользовательский ввод через mysql_real_escape_string» или «всегда использовать подготовленные выражения», мой набор правил не является катастрофическим заблуждением (как первое) или неполным (как второе).
Но вперёд, читатель — перейдём уже к подробному разбору.