Информационный портал по безопасности

В предыдущей части мы улучшили нашу систему логгирования. Вместо использования обменника типа fanout мы использовали обменник типа direct, позволившему нам выборочно принимать сообщения. Не смотря на улучшения, наша система до сих пор имеет ограничения, например мы не можем принимать сообщения основываясь на нескольких критериях. Например в нашей системе мы могли бы хотеть перенаправлять сообщения основываясь не только на уровне строгости сообщения, но и на источнике сообщения. Например как в unix-инструменте syslog, который перенаправляет сообщения не только в зависимости от уровня строгости (info/warn/crit..), но и в зависимости от источника (auth/cron/kern...). Это может дать нам дополнительную гибкость, например мы сможем получать только критические сообщения от 'cron', но также все сообщения от 'kern'. Для реализации такой системы нам предстоит познакомиться с более сложным типом обменника — topic.

В нашей предыдущей статье мы создали очередь задач. Она предполагает что одна задача в виде сообщения доставляются одному получателю. В этой статье мы сделаем кое-что другое, мы будем отсылать одно сообщения сразу нескольким получателям. Мы создадим систему логгирования которая будет состоять из двух программ: первая будет отправлять сообщения, а вторая получать и выводить их. В нашей системе, все запущенные получатели будут получать сообщение отосланное отправителем.

Десять лет назад у нас был классический LAMP-стек: Linux, Apache, MySQL, и PHP, который работал в медленном режиме mod_php. Мир менялся, а с ним и важность скорости. Появился PHP-FPM, который позволил значительно увеличить производительность решений на PHP, а не срочно переписывать на чем-то побыстрее.



Параллельно велась разработка библиотеки ReactPHP с применением концепции Event Loop для обработки сигналов от ОС и представления результатов для асинхронных операций. Развитие идеи ReactPHP — AMPHP. Эта библиотека использует тот же Event Loop, но поддерживает корутины, в отличие от ReactPHP. Они позволяют писать асинхронный код, который выглядит как синхронный. Возможно, это самый актуальный фреймворк для разработки асинхронных приложений на PHP.






Но скорости требуется всё больше и больше, инструментов уже не хватает, поэтому идея асинхронного программирования в PHP — одна из возможностей ускорить обработку запросов и лучше утилизировать ресурсы.



Об этом и поговорит Антон Шабовта (zloyusr) — разработчик в компании Onliner. Опыт больше 10 лет: начинал с десктопных приложений на С/С++, а потом перешел в веб-разработку на PHP. «Домашние» проекты пишет на C# и Python 3, а в PHP экспериментирует с DDD, CQRS, Event Sourcing, Async Multitasking.

Сегодня, наконец, вышел релиз PHP 7.4!


Его новые фичи уже были многократно описаны, в том числе и на Хабре. Это стрелочные функции, типизированные свойства классов и ещё много всякого синтаксического сахара. Но больше всего мы ждали новый релиз из-за производительности: в версии 7.4 не только появился preload, но и сам PHP стал значительно быстрее.



Плохая (или хорошая?) новость — с выходом PHP 7.4 прекращается активная поддержка PHP 7.2. Его последний релиз запланирован на середину декабря. Мы давно проводим эксперименты с PHP 7.4, а недавно активно занялись переходом на него, так как сейчас мы на уже почти не поддерживаемой версии 7.2.



Поздравляю всех с долгожданным релизом! А ниже расскажу немного о том, как мы переходим на новую версию.

Swoft is a PHP high performance microservice coroutine framework. It has been published for many years and has become the best choice for php. It can be like Go, built-in coroutine web server and common coroutine client and is resident in memory, independent of traditional PHP-FPM. There are similar Go language operations, similar to the Spring Cloud framework flexible annotations.

Github

На прошлой неделе столкнулся с крайне неприятным фактом. Зайдя на свой сайт, обнаружил, что он переадресовывает меня на неведомый мне ресурс, на который крайне сильно ругается антивирус Dr. Web



Сайт работает на WordPress актуальной версии 5.1



Все выходящие обновления для движка, плагина и темы устанавливаются вовремя. Плагины только из официального репозитория, тема тоже.

После выхода PHP7 появилась возможность сравнительно небольшой ценой писать долгоживущие приложения. Для программистов стали доступны такие проекты, как prooph, broadway, tactician, messenger, авторы которых берут на себя решение наиболее частых проблем. Но что если сделать небольшой шаг вперёд, углубившись в вопрос?

Попробуем разобрать судьбу ещё одного велосипеда, который позволяет реализовать Publish/Subscribe приложение.

Вышел Yii 2.0.5 исправляющий проблему с безопасностью, найденную в классе yiiwebViewAction. Настоятельно рекомендуется обновиться. Обновление полностью совместимо с 2.0.4, содержит только исправление безопасности и не поломает ваш код.

Уязвимость в ViewAction и заключается в возможности запускать любой PHP файл (или файл с расширением .php) на диске передав относительный путь через параметр view. Так как о проблеме сообщили через публичный трекер, мы исправили её и выпустили обновление немедленно.

Для этой уязвимости мы зарезервировали номер CVE-2015-5467. http://habrahabr.ru/post/262315/#habracut

Вышел Yii 2.0.5 исправляющий проблему с безопасностью, найденную в классе yiiwebViewAction. Настоятельно рекомендуется обновиться. Обновление полностью совместимо с 2.0.4, содержит только исправление безопасности и не поломает ваш код.

Уязвимость в ViewAction и заключается в возможности запускать любой PHP файл (или файл с расширением .php) на диске передав относительный путь через параметр view. Так как о проблеме сообщили через публичный трекер, мы исправили её и выпустили обновление немедленно.

Для этой уязвимости мы зарезервировали номер CVE-2015-5467. http://habrahabr.ru/post/262315/#habracut

В продолжение статьи:

Ускорение и оптимизация PHP-сайта. Какие технологии стоит выбирать при настройке сервера под PHP



В отличии от предыдущего материала, в этой статье сделан упор на сравнение скорости отклика и интерпретации кода для различных версий PHP, включая PHP 7 beta3.

Для ранних версий PHP, проведено тестирование между оптимизаторами кода apc, xcache и opcaсhe.
Эта статья не содержит тестов на производительность, таких как нагрузочные тесты ab и siege. Возможно, об этом я напишу в одной из следующих статей.
В данном случае, меня не интересует сколько страниц за секунду способна сгенерировать та или иная версия php-интерпретатора, скорее то, с какой скоростью она сгенерирует мне страницу и с какой задержкой.
В данном случае разница в том, что тесты производительности замеряют отношение скорости интерпретатора к общим ресурсам сервера, а так же подготовленности других связанных компонентов web-системы к работе на повышенных нагрузках.
Остановимся на скорости и отклике. Очевидно что производительность зависит от скорости, но высокая скорость не может гарантировать высокую производительность. Это, возможно, связанно с тем, что недостаточно хорошо настроен web-сервер или база данных, а также с какими-то не было ограничениями, например сетевого стека.
Что бы не заниматься попыткой объять необъятное, мы просто замерим скорость и отклик работы интерпретаторов php, на мощном сервере без нагрузки, с одинаковыми конфигурациями web-сервера, базы данных и операционной системы для всех испытуемых. Используем конфигурацию php-fpm + nginx. База данных MariaDB. Все технические детали скрыты под спойлером ниже.