Ребята, привет, всех с наступающим Новым Годом!

Я тут немного пропадал, но в любом случае, у меня есть для вас новости, итак что у нас нового в PHP 8.4:

1. В PHP 8.4 появится поддержка AEGIS-128L и AEGIS256 в Sodium
AEGIS - это семейство алгоритмов шифрования с проверкой подлинности на основе AES, которые работают быстрее, чем AES-GCM. Расширение Sodium в PHP 8.4 поддерживает алгоритмы шифрования AEGIS-128L и AEGIS256, если расширение Sodium скомпилировано с версией libsodium 1.0.19 или новее. Расширение Sodium в PHP 8.4 добавляет шесть новых функций и четыре новые константы PHP для AEGIS-128L и AEGIS-256AEAD.

2. Новый метод DateTime createFromTimestamp

До PHP 8.4, чтобы создать экземпляр DateTime или DateTimeImmutable из временной метки UNIX, его нужно было создать с помощью createFromFormat:

$dt = DateTimeImmutable::createFromFormat('U', (string) 1703485481);
$dt->format('Y-m-d'); // "2023-12-25"

С PHP 8.4 классы DateTime и DateTimeImmutable в PHP 8.4 имеют новый метод createFromTimeStamp, позволяющий легко создать экземпляр из заданной временной метки UNIX в виде целого числа или значения с плавающей запятой.

$dt = DateTimeImmutable::createFromTimeStamp(1703485481);
$dt->format('Y-m-d'); //"2023-12-25"

Далее, если вы разработчик своих пакетов PHP, то возможно вам будет полезна информацию о предложении Composer установки девтулсов в require-dev в новом посте
https://sergeymukhin.com/blog/composer-zastavit-ustanovku-paketa-require-dev

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

Всем удачи и хорошего Нового Года!!!

🎄С НОВЫМ 2024 ГОДОМ!🎄

Итак, новый год настал, но расслабляться не будем, ну разве что чуть-чуть)

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

А вот в продолжении к нему, недавно принятый RFC, про cпособ отключения/включения JIT по умолчанию:

До PHP 8.4 JIT был как был и включен и отключен по умолчанию, используя значение по умолчанию opcache.jit_buffer_size=0 вместо opcache.jit=disable. Это фактически отключает JIT не потому, что jit=disable, а потому что размер буфера установлен равный 0.

В этом RFC предлагается изменить эти значения по умолчанию на выключенный jit и размер буфера на 64 мегабайт:

opcache.jit=disable
opcache.jit_buffer_size=64m

Еще одна интересная новость, Валентин Удальцов автор канала Пых опубликовал RFC в котором пасрер PHP может пренебрегать скобками при обращении к объектам, созданным через new, т.е. вместо

(new Class())->method()

можно будет писать:

new Class()->method()

В данный момент это невозможно сделать, т.к. парсер PHP выдаст ошибку синтаксиса. Будем следить за развитием этого RFC.

Ну и как обещал разыграл слона и он уезжает к @Drummi, поздравляю! @Drummi напишите мне в личку адрес, куда я отправлю слона.

Надеюсь 2024 год будет насыщен на новые интересные и полезные RFC PHP.

Всем привет и хороших праздничных выходных!)

Ребят, тут phpcommunity.ru сделало свой ежегодный опрос среди разработчиков, можно неспеша пройти его — до закрытия осталось 3 дня.
Что интересно, там тоже можно будет выиграть php слона)

Ну и как обычно результаты будут в конце января, из них мы узнаем какой сейчас современный пхп разработчик, чем он "дышит" и  интересуется.

https://forms.gle/n9QErGz5iGYrWEzj9

Интересные события произошли в рейтинге TIOBE.

Впервые в истории индекса TIOBE C# получил награду «Язык программирования года». На втором месте Scratch (+0,83%) и Fortran (+0,64%). C# отнимает долю рынка у Java и становится все более популярным в таких областях, как серверная часть веб-приложений и игры (спасибо Unity). C# можно использовать бесплатно, и он постоянно развивается, делая язык более выразительным с каждой новой версией. C# никуда не денется и, возможно, вскоре он сможет даже превзойдет Java.

Помимо C#, в прошлом году в индексе TIOBE произошло много интересных изменений. Fortran и Kotlin навсегда вошли в топ-20 игроков, заменив старых фаворитов R и Perl. Фортран очень хорошо подходит для вычислений с помощью хороших библиотек и остается фаворитом университетов во многих областях. Kotlin — простой в изучении/написании конкурент Java.

Что интересно Julia ненадолго коснулась индекса TIOBE в 2023 году, но не смогла удержать эту позицию.

JavaScript поднялся на 6 место, а PHP на 7-ое.

Привет всем!

Ежегодный пост со статистикой версии PHP из открытых данных экосистемы composer. Статистика версий PHP - выпуск январь 2024.

Похоже, что внедрение PHP 8.3 происходит немного быстрее по сравнению с PHP 8.2: 6,4% проектов используют PHP 8.3 в течение первых двух месяцев после его выпуска, для PHP 8.2 этот показатель в свое время составил 4,7%.

Более того, доля PHP 7.* продолжает сокращаться - и это хорошо, учитывая, что поддержка серии 7.* закончилась более года назад. На данный момент PHP 8.1 является самой старой поддерживаемой версией, обновления безопасности которой будут получать только до 25 ноября этого года. Это важно обновить ваши версии PHP!

А вы уже обновились до PHP 8.3?)

Более подробно, с табличками и графиками https://sergeymukhin.com/blog/statistika-versii-php-vypusk-20241

Врываемся в пятницу! Ребята, всем привет!

Каждый день собираюсь "запоститься" и что-нибудь да отвлекает, итак что имеем на сегодня?

Изменения:

1. Тип констант PHP_ZTS и PHP_DEBUG изменен с int на bool.

PHP_ZTS и PHP_DEBUG - две глобальные константы PHP, которые предоставляют информацию о текущей среде выполнения PHP.

- PHP_ZTS: Указывает, является ли текущая сборка PHP потокобезопасной.
- PHP_DEBUG: Указывает, является ли текущая сборка PHP отладочной сборкой.

До PHP 8.4 эти две константы содержали целочисленные значения: 0 когда отключено и 1 когда включено. Начиная с PHP 8.4 и более поздних версий, они изменились на логические значения.

if (PHP_ZTS === 1) {} //было

if (PHP_ZTS) {} //стало

Устаревшие функции:

2. Константа CURLOPT_BINARYTRANSFER, предоставляемая расширением Curl, устарела в PHP 8.4. Эта константа не имела никакого эффекта, начиная с PHP 5.1.2.

Удаленные функции:

Pspell было перенесено из PHP Core в PECL

Расширение Pspell предоставляет из себя PHP функции проверки орфографии с помощью Pspell или Aspell. Зависимости этого расширения не получали никаких обновлений за последние несколько лет, в результате чего было принято решение расширение Pspell перенести из ядра PHP в расширение PECL в PHP 8.4.

IMAP было перенесено из PHP Core в PECL

В PHP 8.4 расширение IMAP больше не является частью PHP Core и перешло в PECL, рекомендуется перейти на альтернативные библиотеки, например Webklex/php-imap.

OCI8 и PDO-OCI были перенесены из PHP Core в PECL

Расширения oci8 и pdo_oci8 предоставляют функциональные возможности для использования баз данных Oracle в PHP. Эти расширения основаны на собственных библиотеках коммерческого поставщика Oracle. Эти расширения прошли длительный период накопления неисправленных ошибок и требуют значительных усилий для миграции их resource объектов в объекты классов. Учитывая зависимость этих расширений от сторонних проприетарных библиотек и необходимость усилий по их обслуживанию, расширения больше не являются частью ядра PHP и перешли на PECL как oci8 и pdo_oci.

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

Кстати кто не смотрел вчерашнюю трансляцию LivePHP советую к ознакомлению, почерпнете много чего интересного для себя)

https://www.youtube.com/watch?v=DhkTJcjJouc

Всем хороших выходных!

Ребята, приветствую всех!

Сегодня хочу рассказать об очередном интересном принятом RFC в PHP 8.4, который вводит две новых функций:

http_get_last_response_header(): ?array
http_clear_last_response_header(): void

которые можно использовать для получения и очистки HTTP-заголовков последнего ответа HTTP-обертки (wrapper), которые могут заменить историческую переменную $http_response_header.

Напоминаю, что когда вы зайдествуете слой stream'ов, в частности использование HTTP-wrappers (оберток) то всякий раз магически создается переменная $http_response_header в локальной области видмости. Одним из таких способов использования является получение содержимого по URL-адресу file_get_contents():

file_get_contents('https://sergeymukhin.com');

var_dump($http_response_header);
  
array (size=10)
  0 => string 'HTTP/1.1 200 OK' (length=15)
  1 => string 'Server: nginx' (length=13)
  2 => string 'Date: Thu, 07 Mar 2024 07:34:18 GMT' (length=35)
  3 => string 'Content-Type: text/html; charset=UTF-8' (length=38)
  4 => string 'Connection: close' (length=17)
  5 => string 'Vary: Accept-Encoding' (length=21)
  6 => string 'Set-Cookie: PHPSESSID=uea9m7qcm0jgq4t2g3kfolm51h; path=/' (length=56)
  7 => string 'Expires: Thu, 19 Nov 1981 08:52:00 GMT' (length=38)
  8 => string 'Cache-Control: no-store, no-cache, must-revalidate' (length=50)
  9 => string 'Pragma: no-cache' (length=16)

Переменная $http_response_header будет содержать все заголовки HTTP, которые были обнаружены во время запроса.
Мотивация введения новых функций обусловлена более предсказуемый и интуитивно понятный код:

file_get_contents('https://sergeymukhin.com/blog/cto-novogo-v-php-84');

 //$headers = $http_response_header;

 $headers = http_get_last_response_headers(); //запросили заголовки
 http_clear_last_response_headers(); //почистили за собой

Кстати, переменная $http_response_header не модифицируется этими новыми функциями. Т.е.

Очистка $http_response_header не влияет на возвращение значений из http_get_last_response_headers() (она продолжает возвращать все, что было доступно), а вызов http_clear_last_response_headers() не сбрасывает значение в переменной $http_response_header.

Всем доброй пятницы! И хороших выходных!

А пока расскажу про одно из самых значимых RFC в предстоящем PHP 8.4 - RFC1867 для методов HTTP, отличных от POST, которое вводит
новую функцию request_parse_body.

Как вы знаете PHP автоматически анализирует и разбирает HTTP-запросы POST для заполнения глобальных переменных $_POST и $_FILES. Однако другие HTTP-запросы с такими методами, как PUT или PATCH уже не анализируются автоматически, и работа с обработкой данных с данными типами запроса ложится на плечи разработчика/приложения.

Напомню RFC1867 определяет тип контента multipart/form-data. Этот тип контента используется в основном для отправки HTTP-форм, содержащих файлы. PHP изначально поддерживает анализ этого типа контента, но только для запросов POST. В частности, если запрос имеет метод POST и тип содержимого multipart/form-data, тело запроса немедленно используется перед запуском PHP-скрипта и заполняется в суперглобальные переменные $_POST и $_FILES. Эта функция запускается автоматически и не предоставляется непосредственно пользователю.

Учитывая популярность REST API, которые все чаще используют HTTP методы, отличные от POST - такие как PUT, DELETE и PATCH, где использование multipart/form-data полностью допустимо, но не обрабатывается PHP автоматически. Это требует ручного анализа тела запроса нетривиального формата. Обработка больших объемов данных в пользовательской среде также может быть не оптимальной с точки зрения производительности.

Например в Symfony эта часть отвечает за анализ и разбор таких данных, в том же Phalcon мне пришлось в свое время добавить эту возможность и так в любом мало-мальски используемом фреймворке.

Итак, в PHP 8.4 была добавлена ​​новая функция request_parse_body, которая предоставляет встроенную в PHP функциональность анализа запросов для других методов HTTP-запросов, отличных от POST:

function request_parse_body(?array $options = null): array {}


// Например, это запрос PUT
var_dump($_POST); // []
var_dump($_FILES); // []

[$_POST, $_FILES] = request_parse_body();

var_dump($_POST); // уже есть данные [...]
var_dump($_FILES); // уже есть данные [...]


При вызове функция request_parse_body считывает все содержимое, которое доступно в потоке php://input и создает значения, которые можно использовать в переменных $_POST и $_FILES.
Можно заполнить значения $_POST и $_FILES непосредственно из возвращаемых значений:

[$_POST, $_FILES] = request_parse_body();

Параметр $options можно использовать для передачи массива значений INI, связанных с анализом запроса. Эти значения не обязательно должны быть меньше, чем глобальная конфигурация. Это дает преимущество выборочной обработки меньших или больших значений, чем ограничения, установленные в файлах INI.
Например, чтобы проанализировать запрос с большим или меньшим пределом директивы post_max_size INI, можно вызвать функцию request_parse_body с нужным значением:

request_parse_body(['post_max_size' => 1024]);

И небольшое предупреждение: Функция request_parse_body имеет не идемпотентное поведение и предназначена для вызова только один раз за запрос, т.к. имеет разрушительное воздействие на php://input. При последующих вызовах функция вернет массив с пустыми данными, а поток php://input будет пуст после первого вызова request_parse_body().

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

Давайте дружно похлопаем и поблагодарим Илью Товило за столь замечательный функционал!

Чуть больше информации с табличками https://sergeymukhin.com/blog/php-84-novaia-funkciia-request-parse-body

Ребята, всех с праздником!

Хотел успеть запостить статью к 4.04, но не смог сегодня, поэтому пока просто поздравление с профессиональным, успехов в работе и меньше багов!

Ребята, привет!

Если в PHP взять обычный класс, являются ли его свойства свойствами по определению?) Кто подзабыл, напоминаю что такое свойство.

Я думаю вы уже догадались с какими новостями я к вам пришел сегодня, да-да, все верно RFC Хуки свойств (Property hooks) был принят и ожидается в PHP 8.4 (пока прям вот не 100%, но 99% это точно).
Итак, давайте, пробежимся по тому, что имеем и что нам Илья Товило и Ларри Гарфилд преподнесли:

Получение свойства класса или установка его значения является обычной задачей в объектно-ориентированном программировании. В PHP есть несколько способов сделать это.

Возьмем, к примеру, следующий класс.

class User
{
    private string $name;
}

Как вы можете заметить, у нас в классе есть приватное свойство $name. Теперь мы можем определить геттеры и сеттеры для чтения и записи значения свойства соответственно, что до PHP 7.4 можно было считать идиоматическим:

class User
{
    private string $name;

    public function getName(): string
    {
        return $this->name;
    }

    public function setName(string $name): void
    {
        $this->name = $name;
    }
}

$user = new User();
$user->setName('Sergey');

echo $user->getName(); // Sergey

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

class User
{
    public function __construct(public string $name) {}
}

$user = new User('Sergey');

echo $user->name; // Sergey

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

Мы также можем использовать магические методы _ _get и _ _set для достижения того же рез
В PHP 8.4 этот ключевой аспект будет улучшен за счет введения хуков свойств.

Хуки свойств (Propertry Hooks) - это новая функция PHP 8.4, которая позволит вам определять собственную логику для доступа к свойствам и их изменениям. Это может быть полезно для различных случаев использования, таких как мутация, ведение логов, проверка или кэширование.

По сути, Propertry Hooks позволяют вам определять дополнительное поведение свойств класса, используя в основном два хука: get и set. И это будет индивидуально для определенных свойств.

Приведенный ниже дизайн и синтаксис больше всего похож на Kotlin, хотя он также опирается на влияние C# и Swift. Python и JavaScript имеют схожие функции благодаря разному синтаксису, хотя этот синтаксис и непригоден для PHP. Ruby рассматривает свойства и методы почти одинаково, поэтому эта функциональность достигается как побочный эффект. Короче говоря, "средства доступа к свойствам" - очень распространенная функция в основных популярных языках программирования.

Что интересно, авторы просят не пугаться длинному тексту RFC, а предлагают отнестись к этому как глубоко проработанному материалу, отвечающему на все вопросы) Мы конечно пробежимся по самому главному, но если вы хотите узнать детали разработки, то можете почитать оригинальный RFC.

Вот как мы можем написать set для $name свойства в предыдущем примере:

class User
{
    public string $name {
        set (string $value) {
            // валидация имени
            if (mb_strlen(value) < 4)) {
                throw new InvalidArgumentException(
                    'Invalid Name'
                );
            }
            
            // Установка значения
            $this->name = $value;
        }
    }
}

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

Тело хука set - это тело метода произвольной сложности, принимающее один аргумент. Если указано, оно должно включать как тип, так и имя параметра. Здесь мы можем проверить или изменить значение свойства до его установки.

Таким образом, когда свойству присвоено значение $name, будет вызван хук set, и значение будет проверено перед его установкой.

$user = new User();
$user->name = 'Ser'; // Должно вывести исключение InvalidArgumentException

$user = new User();
$user->name = 'Sergey';

echo $user->name; // Sergey

Существует также сокращенный синтаксис для определения хука set с помощью оператора =>, похожий на замыкания:

class User
{
    public string $name {
        set => strtoupper($value);
    }
}

Хук get позволяет вам определить собственную логику для доступа к свойствам. Это может быть полезно для свойств, которые необходимо изменить, прежде чем они будут возвращены пользователю.

Например, если в классе User есть два свойства $name и $lastName, мы можем определить get для свойства $fullName следующим образом:

class User
{
    public function __construct(
        public string $name, public string $lastName
    ) {}

    public string $fullName {
        get {
            return $this->name . " " . $this->lastName;
        }
    }
}

$user = new User('Sergey', 'Mukhin');

echo $user->fullName; // Sergey Mukhin    

Как вы можете заметить, хук get не принимает никаких аргументов. Он просто возвращает значение свойства. Как и обычный геттер.

Таким образом, при доступе к значению $fullName будет вызван хук get, и значение будет возвращено на основе логики, определенной в хуке.

Так же существует сокращенный синтаксис для хука get с помощью оператора =>

class User
{
    public function __construct(
        public string $name, 
        public string $lastName
    ) {}

    public string $fullName {
        get => string $this->name . " " . $this->lastName;
    }
}

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

В RFC упоминается, что, хотя в настоящее время существует два хука свойств, в будущем есть возможность добавить больше, что сделает работу со свойствами еще более мощной.

Можно только поблагодарить Илью Товило и Ларри Гарфилда, в очередной раз создавших столь прекрасный функционал!

https://sergeymukhin.com/blog/php-84-property-hooks

Как отлично заметил Кирилл в комментариях к предыдущим постам, что:

Чтобы устранить необходимость в геттерах и сеттерах, интерфейс должен иметь возможность указать, какие свойства он включает и таким образом в довесок к тому изначально чего он был создан этот RFC также добавляет возможность для интерфейсов асимметрично объявлять публичные свойства. Класс реализации может предоставить свойство как через обычное свойство так и через хук. Любого способа из них достаточно для удовлетворения интерфейса.

Рассмотрим сначала за пример код указанный в RFC:

interface I
{
    // Класс, реализующий интерфейс ДОЛЖЕН иметь публичное свойство,
    // но независимо от того, является ли оно публичным или нет - ограничений нет.
    public string $readable { get; }
 
    // Класс реализации ДОЛЖЕН иметь публичное свойство для записи,
    // но независимо от того, доступно ли оно публичному чтению или нет - ограничений нет.
    public string $writeable { set; }
 
    // Класс реализации ДОЛЖЕН иметь свойство, которое является публичным и
    // доступно для чтения и записи.
    public string $both { get; set; }
}

ну и что-нибудь такое из примеров предыдущих постов:

interface User
{
    // Объекты, реализующие этот интерфейс, ДОЛЖНЫ иметь возможность
    // получить свойство $fullName. Этого можно добиться обычным
    // свойством или свойство с хуком get.
    public string $fullName { get; }
}
 
class Customer implements User
{
    // Хук get необязателен,
    // свойство будет доступно для чтения даже без хука get.
    public function __construct(public string $fullName) {}
}

свойство $fullName будет прекрасно читаться и без хука get. Но если мы определим хук get для свойства, оно будет доступно для чтения именно с помощью хука get.

Интерфейсы могут быть связаны только с публичным доступом, поэтому наличие приватных свойств не зависит от интерфейса и не может удовлетворить интерфейс. Это та же самая логика, что и для методов. Ключевое слово public свойства необходимо для обеспечения согласованности синтаксиса (или его редко используемый псевдоним var).

Следует отметить, что свойство интерфейса, которое требует только хук get может удовлетворяться общедоступным readonly свойством, поскольку ограничения readonly применяются только при записи. Однако свойство интерфейса, которое требует хук set несовместимо с readonly свойством, поскольку публичная запись будет запрещена.

Привет, добрых майских,

продолжая тему RFC с Property Hooks, Brent Roose (автор сайта https://stitcher.io и канала PHP Annotated) провел трансляцию с одним из авторов RFC Ларри Гарфилдом, видео очень интересное, помимо основной темы затрагивались так же около externals/internals вопросы.

Если английский не помеха, советую посмотреть

https://www.youtube.com/watch?v=ULUrhIrjyAg

Всем, привет!

С наступающим праздником и небольшая заметка о возможной грядущей проблеме для кого-нибудь,

Как вы знаете (а может еще не в курсе), но недавно был релиз Mysql 8.4 и среди списка обновлений есть такой пункт как:

default_authentication_plugin: Deprecated in MySQL 8.0.27, and now removed. Use authentication_policy instead

Что логично ведет к отключению устаревшего плагина аутентификации mysql_native_password по умолчанию и полному отказу сервиса MySQL в принципе после обновления, если он у вас используется, а это может произойти как после запуска update и upgrade системы, так и запуск контейнера докера с mysql:latest.

В логах mysql /var/log/mysql/error.log можно увидеть ошибку, валящую СУБД:

2024-05-08T07:15:11.474311Z 0 [ERROR] [MY-000067] [Server] unknown variable 'default-authentication-plugin=mysql_native_password'.
2024-05-08T07:15:11.475302Z 0 [ERROR] [MY-010119] [Server] Aborting 

Либо при попытке подключиться к MySQL:

mysql -u root -p

выдается:

ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded

Решить данную проблему можно, запустив MySQL с новой опцией сервера --mysql-native-password=ON или добавив директиву mysql-native-password=ON в раздел [mysqld] вашего конфигурационного файла MySQL:

#может быть здесь
nano /etc/mysql/mysql.conf.d/default-auth-override.cnf

#или здесь
nano /etc/mysql/mysql.conf.d/mysqld.cnf

открыв файл вы увидите что-то типа:

# This file is automatically generated by MySQL Maintainer Scripts
[mysqld]
default-authentication-plugin = mysql_native_password

приводим его к виду:

# This file is automatically generated by MySQL Maintainer Scripts
[mysqld]
mysql-native-password=ON

и перегружаем или стартуем mysql: service mysql start или service mysql restart

в докере меняем соотвественно команду c :

command: ["mysqld", "--default-authentication-plugin=mysql_native_password"]

на

command: ["mysqld", "--mysql-native-password=ON"]

ну или в любом другом месте где используется default-authentication-plugin=mysql_native_password на mysql-native-password=ON.

Должно все заработать, а вот что делать потом, дело каждого) главное все работает в данный момент и можно спокойно заниматься делами дальше.

Всем доброго дня!

В предыдущем посте с ошибкой unknown variable default-authentication-plugin=mysql_native_password мы смягчили последствия обновления до последней версии MySQL 8.4.

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

Например здесь можно узнать что теперь по-умолчанию в MySQL плагин аутентификации является caching_sha2_password. MySQL предоставляет два плагина аутентификации, которые реализуют хеширование SHA-256 для паролей учетных записей пользователей:

* sha256_password(устарело): реализует базовую аутентификацию SHA-256. Устарел и может быть удален. Не используйте этот плагин аутентификации.

* caching_sha2_password: реализует аутентификацию SHA-256 (как и sha256_password), но использует кэширование на стороне сервера для повышения производительности и имеет дополнительные функции для более широкого применения.

Решение - обновить старые пароли с помощью caching_sha2_password

Перед всеми операциями советую сделать резервную копию базы данных

Итак, первым делом надо вывести список пользователей, использующих плагин mysql_native_password, делаем запрос в MySQL (не важно какой клиент для подключения к MySQL вы используете):

mysql> SELECT user, host, plugin from mysql.user WHERE plugin="mysql_native_password";

Результат будет примерно такой:

+------------------+-----------+-----------------------+
| user             | host      | plugin                |
+------------------+-----------+-----------------------+
| mysql.infoschema | localhost | caching_sha2_password |
| mysql.session    | localhost | mysql_native_password |
| mysql.sys        | localhost | mysql_native_password |
| root             | localhost | caching_sha2_password |
| mukhin           | localhost | mysql_native_password |
+------------------+-----------+-----------------------+
5 rows in set (0.00 sec)

Поскольку caching_sha2_password это новый плагин аутентификации по умолчанию в MySQL 8.x, нам не нужно переопределять метод шифрования пароля дополнительной директивой или флагом. Единственное требование - заново создать/обновить пользователей базы данных с паролем.

Для этого надо будет сделать запрос по шаблону, для каждого пользователя, использующего старый mysql_native_password:

ALTER USER "%user%"@"%host%" IDENTIFIED WITH caching_sha2_password BY "%password%";

Например, чтобы обновить пользователя mukhin на хосту localhost:

ALTER USER "mukhin"@"localhost" IDENTIFIED WITH caching_sha2_password BY "its_not_my_really_password";

После обновления можно проверить, что ваше приложение нормально подключается к MySQL, и после повторного запроса на получение списка пользователей, использующих плагин mysql_native_password уже не выводится.

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

sudo nano /etc/mysql/mysql.conf.d/default-auth-override.cnf

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

# This file is automatically generated by MySQL Maintainer Scripts
[mysqld]
#mysql-native-password=ON

а в докере поубирать упоминание с установкой дефолтного плагина аутентификации:

"--default-authentication-plugin=mysql_native_password"

Делаем рестарт сервиса MySQL:

sudo service mysql restart

и не должны получить ошибок :)

Если вдруг вы удалите или закомментируете директиву #mysql-native-password=ON, а пароль забудете обновить с помощью caching_sha2_password и приложение перестанет работать, вы всегда можете вернуть или расскомментировать конфиг назад и попытаться сделать это снова.