Время от времени мы слышим в кругу разработчиков разговоры о “санации пользовательского ввода” с целью предотвращения атак с использованием межсайтового скриптинга. Эта техника, хоть и придумана из лучших побуждений, приводит к ложному чувству безопасности, а иногда и искажает совершенно корректный ввод.
Ещё одна статья на избитую тему? Да! Потому что за два часа поиска не нашёл ни одной, по которой можно было пройтись от и до и получить работающее окружение.
Шагов, на самом деле, немного, все очень простые, нужно лишь...
Все главные новости из мира Joomla с момента выхода предыдущего дайджеста 24 августа 2022 года в одной статье. Традиционно наш дайджест обозревает новости, расширения, шаблоны и статьи из мира Joomla. Новости расширений, расширения для электронной коммерции и интеграций с Битрикс 24 и AmoCRM, справочные материалы и туториалы, REST API Joomla 4 для разработчиков и многое другое в этой дайджесте.
Всем привет.
Хочу поделиться с вами опытом в парсинге XML файлов размером до четырёх гигабайт. Что бы это происходило быстро, мы читаем файл последовательно, частями, парсим только нужные нам элементы.
В двух словах для быстрого парсинга файлов надо пользоваться XMLReader в связке с yield.
О моей реализации этой связки читайте ниже.
Существует множество разных подходов к построению архитектуры серверных приложений. В данной статье рассмотрим Event-driven архитектуру (она же событийно-ориентированная). Рассмотрим основные принципы, как перейти от связей Компонент А <-> Компонент В, к связям через события Компонент А -> Событие А -> Компонент Б и зачем это нужно?
Продолжим строить подобие JSON-RPC сервера, начатого в части 1 и анализировать его плюсы и минусы. В прошлой статье был описан механизм отделения бизнес логики бэкенда от транспортного протокола (HTTP) через шаблон проектирования "Front Controller", роль которого исполняет в нашем случае JsonRpcController.
Бэкенд API до передачи запроса в код, отвечающий за бизнес логику, обычно предоставляет частичный функционал API шлюза (API gateway) - он может делать аутентификацию, авторизацию, роутинг, валидацию данных, логгирование, кэширование, обеспечивать меры безопасности и другое.
Продолжение поста про интеграцию с ГИС ЖКХ - https://habr.com/en/post/710462/
В этой части разберём как правильно подписать xml-запрос в php при помощи openssl
В этой статье я не разбираю почему xmldsig формируется именно так - я привожу пример реализации. Поэтому я ожидаю, что вы уже знакомы с основными понятиями и алгоритмом подписания по xmldsig.
Будем использовать модифицированную версию openssl из первого поста, поэтому он обязателен к прочтению
В основе всего лежит базовый класс Xml, наследуемый от DOMDocument:
Это ода данному посту и его законное продолжение.
Реализация описана для PHP, но подходит для всех.
Конфиги
Начнём с контейнера, из которого будем общаться с ГИС ЖКХ. Тут приведён конфиг контейнера с продакшена, поэтому есть лишние (для вас) пакеты.
Пока просто посмотрим, пояснения будут после кода.
Для передачи данных по сети есть хорошо зарекомендовавшие себя стандарты - например, SOAP, gRPC, AMQP, REST, GraphQL.
При создании вебсайтов малой, средней и большой сложности с потоками данных к бэкенду и обратно в JSON формате обычно используются последние два с их вариантами. Верней, только варианты, потому что REST и GraphQL - ресурсо-ориентированные стандарты. Это как бы просто перенос элементарной работы с базой данных на клиента (хотя под "ресурсом" может пониматься и абстракция). Обычно таких запросов не больше трети от всего бэкенд API.
Попытка сделать весь API максимально RESTful страшно раздувает код и грузит сеть. Потому что остальные две трети запросов - в форме команд на бэкенд проделать какие-то действия, слабо отображающиеся на CRUD над некими ресурсами. И вариантов послать такие запросы достаточно много. Даже, чересчур.
PHP - едва ли первое, что придет в голову, когда стоит задача поднять сервер веб-сокетов. Практически каждая статья в интернете будет пестрить предложениями использовать для этого NodeJS, Python или Go. Но поскольку PHP - это однозначно первое, что приходит в голову, когда речь идет о веб-приложениях, почему бы не попробовать?
На самом деле, запуск сервера веб-сокетов на PHP довольно прост. Существует превосходная библиотека Ratchet, позволяющая работать на любом фреймворке (или вовсе без него) полноценно и легко.
Казалось бы, на этом разговор можно заканчивать, но мы неизбежно столкнемся с некоторыми ограничениями и проблемами, связанными с архитектурой конечного приложения и природой самого протокола веб-сокетов.
В документации Adobe сочетается большой объем информации и плохая организация этой информации. Поэтому когда перед мной стала задача отправлять документы через Adobe Sign Api, я потратил несколько дней чтобы понять как всё это работает.
И вот моё решение перед вами. Надеюсь, оно сэкономит время и нервы тех кому только предстоит разобраться в этом.
Выковыривание информации из html — это скучно. Очень. Между тем, эта потребность выстреливает редко, но метко (© Суворов). Из-за этого есть спрос на готовые и короткие инструкции о том, как это сделать, чтобы не тратить время на изучение. Перед вами как раз такая.
Чтобы добавить хоть какой-то интерес скучнейшему занятию мы для примера будем парсить пользователей Хабра. А чтобы не мелочиться — ещё и реанимируем для этого экспериментальную библиотеку 11-летней давности.
Есть такой проект — htmlSQL. Старая библиотека времён Очаковских и покоренья Крыма (© Грибоедов). Она позволяет делать выборку из HTML в стиле SQL-запросов как на КДПВ, чем она мне когда-то и полюбилась.
Я новичок, в прошлом году, только начал изучать JavaScript, HTML, CSS и вот я web-администратор в офисе.
Все началось с обычного замечания на утренней планерке — генеральный директор сказал мне: "Видел? На сайте сумма в рублях за доллар соответствует завтрашнему дню, а должна быть еще сегодняшняя!" Все товары, рекламные площадки, клиенты, заказы — все это завязано на валюте, которая обновляется на сутки раньше, чем должна.
И тут я понял что меня ждет очень сложная и почти не выполнимая задача. Ведь я совсем не секу в PHP и с Opencart только месяц как знаком. «Сделаю, конечно!», ответил я, не бить же в грязь лицом.
Мне поставили задачу: сформировать документ через Adobe API. Требований было минимум - главное сформировать документ из шаблона. Шаблон я мог отформатировать в нужный мне формат без проблем. Но сам формат, как его использовать и как это связать с API я не знал. Поэтому нырнул в документацию.
После пары часов изучения, я отчаялся. Информации было море, но нужной информации не нашел. Но зато нашел несколько вариантов документации, пару статей и несколько видео-уроков. Всё это не приблизило меня к цели ни на шаг.
Но спустя несколько дней, огромное количество нервов и желания сдаться, я всё-таки решил задачу. И буду рад поделиться решением тут.
В этой статье я расскажу вам о том, как ровно год назад я связал в цепочку несколько проблем безопасности для достижения Удаленного выполнения кода (RCE) на нескольких серверах компании VK. Я постарался описать свои шаги в подробностях, так как мне самому, как постоянному читателю отчетов по баг-баунти, всегда хочется понять, как исследователь мыслит во время обнаружения необычных уязвимостей. Надеюсь, для вас эта статья будет интересна.
После сканирования 2.6 миллионов доменов на наличие открытых .git каталогов (ссылка на статью), .env (ссылка на статью) и .DS_Store (ссылка на статью) файлов я проделал такое же сканирование для phpinfo-файлов, таких как info.php или phpinfo.php.
В первой части этой статьи я объясню, что такое phpinfo и что из него можно извлечь. Во второй части я расскажу о конфиденциальной информации, которую я нашел.
Список плагинов которые изменят ваше привычное представление о WordPress. Отличная подборка из знаменитых и неизвестных плагинов, которые сделают вашу жизнь в 2023 проще.
API platform это полнофункциональный REST API, который вы получите за считанные минуты. Вот неполный список фич:
- Генерация CRUD
- Поддержка GraphQL
- Машиночитаемая документация API в форматах Hydra и Swagger/Open API, гененрится из метаданных PHPDoc, Serializer, Validator и Doctrine ORM / MongoDB ODM
- Хорошая удобочитаемая документация, созданная с использованием пользовательского интерфейса Swagger (включая песочницу) и / или ReDoc
- Пагинация
- Куча фильтров
- Проверка с использованием компонента Symfony Validator (с поддержкой групп)
- Расширенные правила аутентификации и авторизации
- Расширенная сериализация благодаря компоненту Symfony Serializer (поддержка групп, встраивание отношений, максимальная глубина...)
- Поддержка JWT и OAuth- Файлы и \DateTime, сериализация и десериализация
- Все полностью настраивается благодаря мощной системе событий и сильному ООП.
Низкий порог входа и строгость языка программирования — вещи обычно несовместимые. Потому что ты либо, как Rust, бьёшь по рукам borrow checker’ом — либо, как PHP, позволяешь не задумываться о типах и быстро прототипировать.
На самом деле, если писать код грамотно, это становится неважным и язык перестаёт иметь значение. Архитектура важнее языка, и хороший код на PHP ничем не отличается от аналогичного кода на любом другом ООП-языке. Другое дело, что возможность «любой домохозяйке» писать на PHP сопровождается и риском наворотить полное неподдерживаемое безобразие. Поэтому нам нужны тайпхинты, линтеры, статические анализаторы и подобные инструменты.
Но в PHP есть и ещё один изъян: в нём любой класс, функция или константа — глобальны. Можно создать класс из любого места в коде, и нет способа скрыть его или сделать деталью реализации где-то в отдельной папке. Иными словами, в PHP нет того, что в других языках называется модулями.
Наша новая open-source разработка называется Modulite и внедряет в PHP модули. Это сквозная технология: мы внедряемся в IDE, в PHPStan, в KPHP, в CI, в Composer — и делаем так, будто бы модули нативно есть в языке PHP.
Поднялся вопрос стандартизации коммитов в команде. До этого были такие правила, мы пишем номер задачи и через тире описание того, что было сделано кратко. Номер задачи берется из номера issue. Например: #1 - реализован функционал сборки прода. Но, это надоело и стало как-то неудобно, когда у нас есть четкое деление задач на фиксы, фичи и так далее.
Нашли Conventional Commits и попробовали его на тестовом репозитории, понравилось. Решили внедрить это в команду, но столкнулись с тем, что люди не всегда делают коммиты правильно, а значит нужна какая-то валидация.
В нашей команде принято по максимуму IDE и его возможности. То есть, коммиты мы делаем не через консоль, а через встроенные утилиты. Поэтому, сразу пошли искать плагины, которые есть в PHPStorm и нашли вот эти 2 важных плагина: Conventional Commit и Git Commit Template. После их установки видим новые кнопки в окне коммита:
