Метка «PHP» - 62

При разработке крупных проектов довольно часто возникает ситуация, когда сквозной функционал, слабо относящийся к бизнес-логике, сильно раздувается, заполняя код однотипными конструкциями. Это может быть логирование операций, работа с кешем или проверка прав доступа. Тут нам на помощь приходит АОП.

Для PHP существует несколько реализаций этой парадигмы программирования. К сожалению, среди них мне не удалось найти решение, которое бы можно было легко внедрить в уже существующий большой проект и удовлетворяющее эстетическим требованиям к коду.

Технологии реализации AOP в PHP

Волшебные методы

Самое простое решение — использование «волшебных методов» __call и __callStatic. Эти методы вызываются (если они определены в классе) при обращении к несуществующему методу класса. В качестве аргументов они получают имя несуществующего метода и переданные ему параметры.
В данном случае, приложение строится таким образом, что реальные методы имеют имя отличное от имени указанном в вызывающих их конструкциях. Сквозной функционал реализуется в «волшебных методах», которые, при необходимости, передают управление реальным методам классов.

Плюсы:
  • Легко начать использовать;
  • Реализация не требует дополнительных модулей (нативный PHP).

Минусы:
  • Не удобно использовать при большом количестве сквозного функционала;
  • Т.к. имена методов в определении и в вызовах различаются, создаются трудности при использовании автодополнения кода в IDE.

Предварительный разбор кода

Этот способ подразумевает наличие посредника, позволяющего использовать «синтаксический сахар». Необходимый функционал описывается вспомогательным синтаксисом (xml/json конфигурация, дополнительные php-классы или аннотации в коде), который разбирается посредником. На основе разбора генерируется результирующий код, который содержит вставки сквозного функционала в необходимые места.

Плюсы:
  • Работает быстро, т.к. на выходе это обычный PHP-код, просто сгенерированный за Вас автоматически.

Минусы:
  • Сложно внедрить в большой проект;
  • Требуется разбор кода после каждого изменения, для внесения корректировок в результирующий код.

Замена кода приложения во время выполнения

Читать полностью »

Товарищи! Эта статья не для high-high-highload систем. Скорость работы представленных решений определённо меньше простейших проверок. На многотысячных или очень глубоких структурах применять предлагаемый подход крайне не рекомендуется. В этом топике побеждает быстрое кодирование, а не быстрый код.

Без длинных

Давайте без длинных вступлений, но всё же с предысторией. Однажды в рамках создания очередного очень важного компонента веб-сервиса нам понадобилось проверять уйму очень разных входных параметров (в данном случае, пришедших через $_REQUEST). Компонент был очень сложный, внутренняя и внешняя логика вызывала ежедневный баттхёрт между всеми участниками, а отдуваться приходилась немногим «избранным» программистам, которые писали, переписывали, выпиливали и запиливали заново. Когда на вход в систему с фронтенда падают десятки разных переменных, в том числе массивов, программисты при этом делают перекрёстные задачи (меняя логику) и мешают друг другу — код очень быстро разрастается, количество цепочек if-ов начинает занимать не одну страницу. Возвращаться к такому коду всё более и более чуждо ранимой душе. Тесты уже не очень помогают, т. к. каждое изменение логики приводит к изменению тех же тестов, в которых ещё надо вспомнить, понять и простить. Вот тогда и встал вопрос о создании удобного способа проверять весь входной поток каким-то приятным глазу способом, да чтоб всегда и везде получать фидбек про ошибки в однотипном виде. Акцент тут изначально стоял именно на удобстве для разработчиков, строго прошу в дальнейшем иметь.
Читать полностью »

К своему удивлению, я не нашёл на Хабре исчерпывающей статьи на тему защиты от инъекций. Поэтому решил написать свою.

Несколько пространный дисклеймер, не имеющий прямого отношения к вопросу

Давайте признаем факт: количество статей (и комментариев) на тему защиты от SQL-инъекций, появившихся на Хабре в последнее время, говорит нам о том, что поляна далеко не так хорошо истоптана, как полагают некоторые. Причём повторение одних и тех же ошибок наводит на мысль, что некоторые заблуждения слишком устойчивы, и требуется не просто перечисление стандартных техник, а подробное объяснение — как они работают и в каких случаях должны применяться (а в каких — нет).

Статья получилась довольно длинной — в ней собраны результаты исследований за несколько лет — но самую важную информацию я постараюсь компактно изложить в самом начале, а более подробные рассуждения и иллюстрации, а так же различные курьёзы и любопытные факты привести в конце. Также я постараюсь окончательно развеять множественные заблуждения и суеверия, связанные с темой защиты от инъекций.

Я не буду пытаться изображать полиглота и писать рекомендации для всех БД и языков разом. Достаточное количество опыта у меня есть только в веб-разработке, на связке PHP/MySQL. Поэтому все практические примеры и рекомендации будут даваться для этих технологий. Тем не менее, изложенные ниже теоретические принципы применимы, разумеется, для любых других языков и СУБД.

Сразу отвечу на стандартное замечание про ORM, Active record и прочие query builders: во-первых, все эти прекрасные инструменты рождаются не по мановению волшебной палочки из пены морской, а пишутся программистами, используя всё тот же грешный SQL. Во-вторых, будем реалистами: перечисленные технологии — хорошо, но на практике сырой SQL постоянно встречается нам в работе — будь то legacy code или развесистый JOIN, который транслировать в ORM — себе дороже. Так что не будем прятать голову в песок и делать вид, что проблемы нет.

Хоть я и постарался подробно осветить все нюансы, но, вполне возможно, некоторые из моих выводов могут показаться неочевидными. Я вполне допускаю, что мой контекст и контексты читателей могут различаться. И вещи, которые кажутся мне сами собой разумеющимися, не являются таковыми для некоторых читателей. В этом случае буду рад вопросам и уточнениям, которые помогут мне исправить статью, сделав её более понятной и информативной.

Ещё только начав интересоваться темой защиты от инъекций, я всегда хотел сформулировать набор правил, который был бы одновременно исчерпывающим и компактным. Со временем мне это удалось:

Правила, соблюдение которых гарантирует нас от инъекций

  1. данные подставляем в запрос только через плейсхолдеры
  2. идентификаторы и ключевые слова подставляем только из белого списка, прописанного в нашем коде.

Всего два пункта.
Разумеется, практическая реализация этих правил нуждается в более подробном освещении.
Но у этого списка есть большое достоинство — он точный и исчерпывающий. В отличие от укоренившихся в массовом сознании правил «прогонять пользовательский ввод через mysql_real_escape_string» или «всегда использовать подготовленные выражения», мой набор правил не является катастрофическим заблуждением (как первое) или неполным (как второе).

Но вперёд, читатель — перейдём уже к подробному разбору.
Читать полностью »

Меня зовут Дмитрий, мне 17 лет, в этом году поступил в НУВГП на факультет прикладная математика.
В топике пойдет речь о моем (пока не долгом) жизненном пути к программированию.
Читать полностью »

Вашему вниманию предлагается небольшой набор функций, каждая из которых может пригодится веб-разработчику. Большинство из них нетрудно найти в интернете, но я не смог найти ни одну страницу, где была бы представлена хотя бы половина описанного.Читать полностью »

Хабрастатистика

Собственно после появления довольно интересного и популярного топика Хабракамп товарищ opium создал вопрос, где предложил создать скрипт статистики.

Несмотря на работу, личную жизни и другие факторы, которые затянули создание скрипта, я все-таки его допилил до какой-то кондиции.

Также я столкнулся с проблемами, которые раньше еще не видал.
Полезный опыт, как никак.
Читать полностью »

Частота обновления (передачи данных с веб-сервера в браузер клиента), как правило, ограничивается хостинг-провайдерами, так что, как владелец сайта, Вы должны убедиться, что он использует как можно меньше трафика, чтобы избежать дальнейших проблем.
В этой статье я опишу несколько наиболее полезных советов, чтобы сохранить максимальное количество трафика, и сделать свой ​​сайт очень быстрым.
Читать полностью »

Частота обновления (передачи данных с веб-сервера в браузер клиента), как правило, ограничивается хостинг-провайдерами, так что, как владелец сайта, Вы должны убедиться, что он использует как можно меньше трафика, чтобы избежать дальнейших проблем.
В этой статье я опишу несколько наиболее полезных советов, чтобы сохранить максимальное количество трафика, и сделать свой ​​сайт очень быстрым.
Читать полностью »

Искусство каррирования
Вдохновившись статьей Еще раз о каррировании и частичном применении в PHP, в голову пришла реализация частичного применения метода, именно метода, а не функции.
Читать полностью »

Возникла нужда сделать универсальный парсер.

Задача

Имеется n сайтов (интренет магазинов), таких как ebay, buy. Нужно получить данные такого вида:

  • Title / Название продукта
  • Picture / Изображение продукта
  • Price / Цена

Всё должно в примерннотаком порядке:

  1. Подаём ссылку, например: www.buy.com/prod/mxl-condenser-microphone-and-pop-filter-bundle-mxl-2008-pf001/224516871.html
  2. В ответ получаем наши данные, тайтл, картинку, и цену. С возможностью редактирования
  3. Постим данные в наш сайт

Проблема

Данные должны также успешно парсится с любого интрнет магазина, при этом 100% результат должен получаться не меньше чем в 6 случаях из 10.

Варианты решения задачи

  • PHP parser по шаблону
  • JS parser с поиком слоёв рядом находящихся
  • Что-то другое

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js