Не входит в админку Revo 2.4.4

Здравствуйте, уважаемые форумчане!
Столкнулся с необычной проблемой — перестал работать вход в админку.
После ввода логина и пароля — страница обновляется, ничего не происходит.
Восстановление пароля через письмо на почту не работает — новый пароль приходит, но в админку войти не получается.
Изменение пароля через БД не помогает — пробовал шифрование PBKDF2 и MD5.
Изменение пользователя через API дает тот же результат, равно как и создание нового пользователя с правами администратора.

Папку кэша чистил, папка логов внутри не создается. (в том числе при открытии разных страниц на фронтенде).
В логе php ошибок нет.

В чем может быть затык?
Думаю переустановить движок (или, может быть, если смысл обновить до более новой версии?)

UPD:
Переустановка на ту же версию результатов не дала.
При вводе неправильного пароля получаю стандартную ошибку, при вводе правильного пароля — страница обновляется.

UPD2:
Было испробовано много способов, решения проблемы не нашел. Переношу контент на чистую версию движка импортом таблиц из БД.
Кто столкнется с таким же — попробуйте залогиниться принудительно. Возможно подтолкнет к решению (или точно поймете, что проблема та же, что у меня).
В комментариях много дельных советов.

Всем ОГРОМНОЕ спасибо за помощь и советы!

Олег

15 января 2017, 17:13

8 198

Комментарии: 18

Rrp2010

15 января 2017, 21:16

Может так откроется: a href=«https://адрес.ru/manager/index.php?a=resource/update&id=1?

Еще:
Активна или нет учётная запись пользователя. Если не активна, то пользователь не сможет авторизоваться на сайте или в бэкэнде.

Олег

15 января 2017, 21:22

Учетная запись активна и не заблокирована.
Также пробовал вот обнулять таблицу сессий (углядел решение в интернете), но результата также не получил.
Попробовал на всякий случай поменять адрес админки, ничего не поменялось (кроме, собственно, адреса админки).

Первый раз с таким столкнулся, на том же сервере лежат около сотни сайтов на modx, все работают без нареканий — один этот выделяется.

Владимир

15 января 2017, 21:21

Если у вас недостаточно места на сервере для создания кэша- как раз такая картина будет как вы описываете
Зайдите в базу данных, сотрите сессии, зайдите по фтп или sftp и удалите папку с кешем

Олег

15 января 2017, 21:24

Сайт занимает 71мб из разрешенных (мной же) 1000.
Таблицу сессий уже обнулил, кэш чистил около 15 раз (после каждого изменения).

Владимир

15 января 2017, 21:27

Глупую вещь скажу тогда, раз сайт так невелик, то закинь его на modhost, это недолго, там и обнови движок, ибо версия уж больно древняя, все равно надо бы уже обновить.

Олег

15 января 2017, 21:32

Версия уже последняя, 2.5.4
Но можно попробовать на modhost, вдруг заработает :)
Благодарю за идею

Владимир

15 января 2017, 21:32

или в базе отключайте плагины по одному

Дмитрий Ломакин

15 января 2017, 21:37

права доступа и владельца на папки файловой системы проверьте
и на папку /var/lib/php/session (на centOS) или где там у вас хранится…

Олег

15 января 2017, 21:48

На папки 755, на файлы 644.

и на папку /var/lib/php/session (на centOS) или где там у вас хранится…

С этим пока не знаком, сейчас поищу информацию на эту тему…
Но на там же сервере находятся многие десятки сайтов на modx, все работают безукоризненно.
Этот сломался ни с того, ни с сего. Настроек сервера никто не менял.

Пока в голову не приходит, чем он так выделился от остальных.

Дмитрий

15 января 2017, 22:11

У меня в прошлом году часто случалась точно такая же ситуёвина на древнем хостинге (приходилось хостить сайты там, так как у студии был выделенный сервер у этого хостера).
Помогало вот это

Дмитрий Суворов

16 января 2017, 01:31

+1.

Была пару раз именно такая проблема, помогала именно очистка таблицы «modx_session».

~~Fi1osof~~

16 января 2017, 03:46

В manager/index.php сразу после $modx->initialize(); пишете:

$modx->user = $modx->getObject("modUser", $admin_user_id);
$modx->user->sudo = 1;
$modx->user->addSessionContext("mgr");

И обновляете страницу админки.
Если не поможет, то совсем плохо дела.

А вообще проверьте системные настройки site_url|manager_url или типа того, returnUrl у вас сбитый joxi.ru/eAOqaVNfx9jojm (но это так, на всякий случай). Но скорее всего проблема просто в том, что у вас кукисы двоятся. Не экспериментировали с указанием домена для кукисов? То есть авторизация проходит, и страница обновляется (что нормально), но сессия не держится.

Олег

16 января 2017, 10:26

Благодарю, идея с принудительной авторизацией замечательная!
Виден первый сдвиг:

С админкой творится что-то странное, обычно супротив такого помогала очистка кэша.
Не работает ни одна страница кроме manager/index.php

Внизу страницы есть список залогиненых пользователей, и там указано, что авторизация проходила.
Судя по всему проблема именно с сессией или кукисами. Сейчас попробую проверить остальные советы на всякий случай…

Теперь хотя бы есть, куда копать :) Спасибо!

Олег

16 января 2017, 11:41

В таблице системных настроек не увидел site_url, manager_url.
Пути в config.core.php прописаны верно, кэш сброшен… Я так понимаю эти значения устанавливаются после сброса кэша, так что значения должны быть нормальные.

С кукисами на modx никогда не работал, да и вообще с ними опыт небольшой. Попробую сейчас нагуглить что-нибудь на эту тему.

Вроде бы определил проблему:
modx.pro
В записях modx_session в конце не хватает «modx.mgr.user.config|a:0:{}», но решение из поста не помогает.

~~Fi1osof~~

16 января 2017, 14:42

Да у вас там скорее всего редиректы какие-нибудь. Просто так ничего не бывает, смотрите какие коды отдают Ajax-запросы. Принудительная авторизация работает, значит уже ОК.

Олег

16 января 2017, 16:54

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

Благодарю за помощь! Очень ценные советы.
Заодно получше разобрался в устройстве движка, какой-никакой, а плюс :)

~~Fi1osof~~

17 января 2017, 02:33

На здоровье!

akkmeno

31 июля 2017, 04:55

Возникла такая же проблема при переносе на хостинг timeweb. Докопался до того, что неправильно формируются переменные сессии при логине. Задал их вручную в файле manager/index.php
Нижнюю часть, начиная с $modx->initialize('mgr') заменил на:

if (isset($_POST['username']) && isset($_POST['password']) && $_POST['username']=='логин_админа' && $_POST['password']=='здесь_пароль'){
    $modx->initialize('mgr');
    $_SESSION['modx.user.0.resourceGroups']['mgr'][0]=1;
    $_SESSION['modx.user.0.attributes']['mgr']['modAccessContext']['web'][0]['principal']=0;
    $_SESSION['modx.user.0.attributes']['mgr']['modAccessContext']['web'][0]['authority']=0;
    $_SESSION['modx.user.0.attributes']['mgr']['modAccessContext']['web'][0]['policy']['load']=1;
    $_SESSION['modx.user.0.attributes']['mgr']['modAccessResourceGroup'][1][0]['principal']=0;
    $_SESSION['modx.user.0.attributes']['mgr']['modAccessResourceGroup'][1][0]['authority']=0;
    $_SESSION['modx.user.0.attributes']['mgr']['modAccessResourceGroup'][1][0]['policy']['list']=1;
    $_SESSION['modx.user.0.attributes']['mgr']['modAccessResourceGroup'][1][0]['policy']['load']=1;
    $_SESSION['modx.user.0.attributes']['mgr']['modAccessResourceGroup'][1][0]['policy']['remove']=1;
    $_SESSION['modx.user.0.attributes']['mgr']['modAccessResourceGroup'][1][0]['policy']['save']=1;
    $_SESSION['modx.user.0.attributes']['mgr']['modAccessResourceGroup'][1][0]['policy']['view']=1;
    $_SESSION['modx.user.contextTokens']['mgr']=1;
    $_SESSION['modx.user.contextTokens']['web']=1;
    $_SESSION['modx.mgr.user.token']= $modx->getObject('modUser',$id_admin)->generateToken('mgr');
    $_SESSION['modx.web.user.token']= $modx->getObject('modUser',$id_admin)->generateToken('web');
    $_SESSION['modx.web.user.config']=$_SESSION['modx.mgr.user.config'];
    $_SESSION['modx.mgr.session.cookie.lifetime']=0;
    unset($_SESSION['modx.{mgr}.user.config']);
    unset($_SESSION['modx.user.config']);
    unset($_POST);
    echo "<body onload='window.location.href=`адрес_сайта`'>";    
    @session_write_close();
    exit();
}
else {
    $modx->initialize('mgr');
    
    $modx->getRequest();
    $modx->getParser();
    if (!MODX_API_MODE) {
        $modx->request->handleRequest();
    }
    @session_write_close();
    exit();
}

Для сравнения какими должны быть переменные сессии использовал тот же сайт на другом хостинге где все работало. Обнаружил, что на timeweb создается переменная $_SESSION['modx.{mgr}.user.config'] вместо $_SESSION['modx.mgr.user.config'], а также $_SESSION['modx.user.config'], которой на нормально работающем сайте вообще нет.
Переменные $_SESSION['modx.user.contextTokens'] и $_SESSION['modx.web.user.token'] вообще не создаются.
Дальше копать не стал почему они не создаются, так как надо, чтобы админка работала в понедельник.
Однако проблему желательно решить нормальным способом, а не таким педальным как я выше привел))

Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.