Как установить root пароль для MySQL в Debian 9 (или MySQL 5.7+, MariaDB 10.1+)

Одно из новшеств новых версий MySQL и его свободного ответвления под названием MariaDB, является организация аутентификации пользователей базы данных. Мы привыкли, что после установки mysql-server, следующим шагом задаём root пароль, однако, после установки mysql-server в Debian 9, мы столкнёмся с тем, что ожидаемое «окно» ввода root пароля не появится, а все инструкции в интернетах по установке root пароля MySQL не сработают. Дело в том, что теперь под пользователем MySQL root можно авторизовываться только через auth_socket, например, в консоли через mysql-client из под unix root пользователя, без ввода пароля: mysql -u root.

Такие дела. Все эти mysqladmin -u root password, SET PASSWORD FOR root@localhost=PASSWORD, UPDATE user SET Password=PASSWORD(… не помогут. Утверждают, это повышает безопасность.

Но это, мягко скажем, не очень удобно для организации и управления базами данных, а также создания новых пользователей этих баз данных, когда есть, например, phpMyAdmin, предоставляющий комфортный веб-интерфейс для рутинных действий. Поэтому заходим в mysql-client из под unix root пользователя:

Читать дальше…

Безопасное хранение учётных данных в PHP

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

Хоть и множество проблем, связанных с защитой секретных данных, может быть устранено с помощью более менее «секретной обработки”, но, тем не менее, кажется, что всё ещё имеет место быть потребность в сохранении секретных данных прямо в коде. Использование такого рода паттерна, очевидно, не рекомендуется. В базе данных Common Weakness Enumeration есть даже запись об этом: CWE-798. Жёстко закодированные учётные данные могут представлять огромный риск, если злоумышленник каким-то образом смог получить доступ к коду и прочесть их.

Так что насчёт PHP?

В PHP приложениях существует общий паттерн для хранения конфигураций и доступов в .env файлах, располагаемый в директории, доступной для чтения из PHP. Поскольку это обычная практика, то я не хочу отходить слишком далеко от неё. Я предложу нечто такое, что сможет легко заменить это, но по-прежнему будет как можно проще.

Мы пройдёмся по нескольким хорошим методам хранения учётных данных, обсудим, что в них хорошего и плохого. Все они будут использовать простые методы хранения, основанные на коде или в соответствующем простом файле (например, в .env). Мы начнём с худшего варианта — сохранение учётных данных в текстовом виде в коде.

Читать дальше…

Решение: Qt Creator «Отсутствуют подходящие комплекты»

Если при попытке собрать проект, вы обнаруживаете, что нет неких комплектов для сборки, то похоже, что вы установили qtcreator без SDK. Поэтому нужно сделать следующее:

apt install qt-sdk

И перезапустить Qt Creator.

Если после этого при компиляции возникнет ошибка «qt creator needs a compiler setup to build», то выберите в параметрах компилятор:

Профайлинг PHP приложений

Анализ времени вызовов методов и функций позволяет найти «бутылочное горлышко» в проекте для последующей оптимизации.

Установим XDebug и инструмент для просмотра профайлинг-логов, например KCacheGrind.

apt install php-xdebug kcachegrind

Затем активировуем профайлинг в php.ini (путь до файла зависит от конфигурации веб-сервера):

mcedit /etc/php/7.0/fpm/php.ini

Добавив в конец:

xdebug.profiler_enable = On
xdebug.profiler_output_name="cachegrind.out.%H.%R.%u"

Перезапустим PHP сервер:

service php7.0-fpm reload

Теперь после каждого открытия PHP приложений, в /tmp (по умолчанию) будут создаваться файлы с именем cachegrind.out.ХОСТ.REQUEST_URI.ВРЕМЕННАЯ_МЕТКА.

Эти файлы можно открыть через KCacheGrind.

Как автоматически создавать геттеры и сеттеры

Всевозможную рутину следует автоматизировать. В создании геттеров и сеттеров нет никакой интеллектуальной деятельности, с этим справится простейший алгоритм. В PhpStorm для таких целей существуют генераторы, среди которых есть и генератор геттеров и сеттеров:

ПРАВИЛЬНОЕ решение: But these conflict with your requirements or minimum-stability

Если вы загуглите исправление ошибки Composer «But these conflict with your requirements or minimum-stability», то, вероятнее всего, наткнётесь на совет добавить в composer.json параметр:

"minimum-stability": "dev"

Однако, это только половина решения, но приводящая к тому, что пакеты, имеющие несколько версий (dev, beta, stable), будут ставиться в версии dev (разрабатываемой) с соответствующими нежеланными и неожиданными последствиями и нестабильностью.

Чтобы этого избежать, нужно добавить ещё один параметр — prefer-stable. Он говорит Composer предпочитать стабильные версии пакетов и только в случае, если таковых нет, устанавливать версии, удовлетворяющие заданную минимальную стабильность (в данном случае dev).

Таким образом, чтобы исправить ошибку Composer «But these conflict with your requirements or minimum-stability», необходимо в composer.json добавить параметр prefer-stable в паре с minimum-stability:

{
    ...,
    "require": {
       ...
    },
    "prefer-stable": true,
    "minimum-stability": "dev"
}

Отключаем запуск внешних программ через PHP

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

Это очень полезная возможность при создании сервисов и других приложений посложнее сайтиков.

Но на серверах, на которых работают только типичные сайты (например, на CMF или CMS), данные функции могут быть использованы скрипт-кидди и прочими хакерами, эксплуатирующими уязвимости тех же CMS. И, даже ограничивая поле деятельности сайта в рамках его каталога хоста, с помощью запуска внешних программ разрушительные действия могут вырваться за пределы этой песочницы.

Читать дальше…

Никогда не используйте NULL

Когда мы вместе с клиентами проводим код-ревью, регулярно наблюдаем одну и ту же картину, которую я считаю проблематичной во многих отношениях – использование null в качестве допустимого свойства или возвращаемого значения. Можно же сделать лучше.

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

Для чего это используется

Примером частого сценария использования может быть внедрение дополнительных зависимостей через метод класса:

class SomeLoggingService {
    private $logger = null;

    public function setLogger(Logger $logger) {
        $this->logger = $logger;
    }
}

 

В большинстве случаев logger будет установлен, но кто-то забудет об этом при использовании вашего сервиса. На сцену выходит второй разработчик и пишет новый метод в этом классе, используя свойство $logger. Во время разработки свойство всегда устанавливается и тестируется по соответствующим сценариям использования, так что разработчики забывают проверять на null – очевидно, это станет проблемой при других обстоятельствах. Вы полагаетесь на то, что методы будут вызваны в определённом порядке, который сложно документировать. Метод getLogger(), создающий нулевой логгер по умолчанию, мог бы решить эту проблему, но не гарантировано, поскольку второй разработчик может не знать об этом методе и просто использовать свойство.

Читать дальше…

Суперскоростной Symfony с помощью nginx

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

Фреймворки, такие как Symfony, потенциально позволяют создавать суперскоростные приложения. Мы уже видели один способ как добиться этого (путём превращения приложения в HTTP сервер), другой способ заключается в установке обратного прокси перед ним.

В данной статье мы возьмём Symfony приложение и увидим, как увеличить его производительность в 140 раз с помощью nginx.

Читать дальше…

Почему PHP-разработчики думают, что MVC – это архитектура приложения?

Ранее я указывал на то, что Model-View-Controller представляет собой паттерн пользовательского интерфейса, а не архитектуру приложения. Но откуда у PHP-разработчиков возникла идея, что MVC – это в первую очередь архитектура? (Это можно сказать обо всех разработчиках серверной части, не только о PHP)

Я одно время думал, что MVC — это архитектура. Даже после прочтения «Каталога шаблонов корпоративных приложений» Фаулера и, несмотря на то, что MVC предназначался для пользовательского интерфейса, я полагал, что всё правильно понял и делаю «приложение пользовательского интерфейса». Но это было не совсем так; правильнее было бы сказать, что я смешивал проблемы пользовательского интерфейса с основой ядра приложения.

Читать дальше…

Асинхронные контроллеры в Symfony

Асинхронное программирование в последние годы стало синонимом высокой производительности в веб-приложениях со стороны сервера. Во многом это связано с возрастающей популярностью изначально асинхронных JavaScript и Node.js.

Как и многие другие вещи, асинхронное программирование не является чем-то новым. Вы можете использовать этот стиль программирования во многих средах, начиная с Python и заканчивая .NET.

В браузере отдельные события, такие как клик мыши, помещаются в цикл обработки событий (см. What the heck is the event loop anyway?, Филип Робертс), а затем события обрабатываются асинхронно без определённой очерёдности: нельзя точно узнать, когда событие клика мыши выполнится.

Ключевое место в асинхронности занимает I/O. В браузерах данное понятие включено начиная с Internet Explorer 5.0 и популяризировано Gmail в 2004 году. Придуманный метод, AJAX, позволил браузерам выполнять запросы к серверу после первоначальной загрузки страницы.

На сервере неблокирующий асинхронный I/O позволяет, например, продолжать выполнять другие задачи, вместо того, чтобы ожидать выполнения долгих запросов к базе данных. Существует много механизмов для обработки потоков асинхронного кода, такие как фьючерсы/promises, генераторы и наблюдатели.

Так что асинхронное программирование не разгоняет ваш компьютер, чтобы получить более высокую производительность. Оно может только помочь компьютеру использовать более эффективно ресурсы путём устранения потерь времени на ожидание.

Асинхронный PHP

Читать дальше…