Собственно копая макрос, с целью внедрения прозрачной авторизации емейл/телефон/логин, с удивлением увидел в макросе отвечающем за логин пользователя, строчки, поставившие меня в тупик, с вопросом "это что за индусский подход?"
if ($user instanceof iUmiObject) {
if (\UmiCms\Service::Session()->get('fake-user') == 1) {
return ($this->restoreUser(true)) ? $this->auth() : $res;
}
[b]$hashedPassword = $user->getValue('password');[/b]
$hashAlgorithm = UmiCms\Service::PasswordHashAlgorithm();
if ($hashAlgorithm->isHashedWithMd5($hashedPassword, $rawPassword)) {
$hashedPassword = $hashAlgorithm->hash($rawPassword, $hashAlgorithm::SHA256);
[b]$user->setValue('password', $hashedPassword);
$user->commit();[/b]
}
.....
Это что, мы проверяем хэш пароля, и если он корректен, то мы коммитим его обратно в базу ? О_о
Или тут происходит что-то другое, и я просто туплю ?
Блин, расписав вопрос, понял и ответ. Происходит смена хэша для пароля, с мд5 на sha256. Рукалицо )
Это получается эдакая заплатка для старых юзеров, регавшихся ещё под старой версией системы.
Если кому будет нужно, задача решилась примерно таким образом:
/classes/system/subsystems/models/auth/AuthenticationRules/LoginAndPassword.php
содержит в себе public function validate()
добавляем в неё:
$phone_number = preg_replace("/[^0-9]/", '', $login);
try {
$queryBuilder = $this->getQueryBuilder();
//*тут изменения
if (strlen($phone_number) == 11){
$queryBuilder->option('or-mode')->fields('login', 'e-mail','phone');
$queryBuilder->where('phone')->equals($phone_number);
}
else{$queryBuilder->option('or-mode')->fields('login', 'e-mail');}
......
Ну или модифицируем по желанию. Я добавил проверку на дублирующийся номер телефона, и в случае совпадения перебор корректных пар логин/пароль. С уведомлением себя любимого на почту, о таком странном казусе.
Если у вас лицензия все ещё активна, или вы планируете дальнейший апгрейд юми, то функцию стоит переопределить, или вообще переписать макрос login_do в кастом.