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

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

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

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

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

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

Всем ОГРОМНОЕ спасибо за помощь и советы!
Олег
15 января 2017, 17:13
modx.pro
1
7 011
0

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

Rrp2010
15 января 2017, 21:16
+1
Может так откроется: a href=«https://адрес.ru/manager/index.php?a=resource/update&id=1?

Еще:
Активна или нет учётная запись пользователя. Если не активна, то пользователь не сможет авторизоваться на сайте или в бэкэнде.
    Олег
    15 января 2017, 21:22
    0
    Учетная запись активна и не заблокирована.
    Также пробовал вот обнулять таблицу сессий (углядел решение в интернете), но результата также не получил.
    Попробовал на всякий случай поменять адрес админки, ничего не поменялось (кроме, собственно, адреса админки).

    Первый раз с таким столкнулся, на том же сервере лежат около сотни сайтов на modx, все работают без нареканий — один этот выделяется.
    Владимир
    15 января 2017, 21:21
    +1
    Если у вас недостаточно места на сервере для создания кэша- как раз такая картина будет как вы описываете
    Зайдите в базу данных, сотрите сессии, зайдите по фтп или sftp и удалите папку с кешем
      Олег
      15 января 2017, 21:24
      0
      Сайт занимает 71мб из разрешенных (мной же) 1000.
      Таблицу сессий уже обнулил, кэш чистил около 15 раз (после каждого изменения).
        Владимир
        15 января 2017, 21:27
        +1
        Глупую вещь скажу тогда, раз сайт так невелик, то закинь его на modhost, это недолго, там и обнови движок, ибо версия уж больно древняя, все равно надо бы уже обновить.
          Олег
          15 января 2017, 21:32
          0
          Версия уже последняя, 2.5.4
          Но можно попробовать на modhost, вдруг заработает :)
          Благодарю за идею
          Владимир
          15 января 2017, 21:32
          +1
          или в базе отключайте плагины по одному
        Дмитрий Ломакин
        15 января 2017, 21:37
        +1
        права доступа и владельца на папки файловой системы проверьте
        и на папку /var/lib/php/session (на centOS) или где там у вас хранится…
          Олег
          15 января 2017, 21:48
          0
          На папки 755, на файлы 644.
          и на папку /var/lib/php/session (на centOS) или где там у вас хранится…
          С этим пока не знаком, сейчас поищу информацию на эту тему…
          Но на там же сервере находятся многие десятки сайтов на modx, все работают безукоризненно.
          Этот сломался ни с того, ни с сего. Настроек сервера никто не менял.

          Пока в голову не приходит, чем он так выделился от остальных.
          Дмитрий
          15 января 2017, 22:11
          1
          +2
          У меня в прошлом году часто случалась точно такая же ситуёвина на древнем хостинге (приходилось хостить сайты там, так как у студии был выделенный сервер у этого хостера).
          Помогало вот это
            Дмитрий Суворов
            16 января 2017, 01:31
            +1
            +1.

            Была пару раз именно такая проблема, помогала именно очистка таблицы «modx_session».
            Fi1osof
            16 января 2017, 03:46
            1
            +2
            В 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
              +1
              Благодарю, идея с принудительной авторизацией замечательная!
              Виден первый сдвиг:

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

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

              Теперь хотя бы есть, куда копать :) Спасибо!
                Олег
                16 января 2017, 11:41
                0
                В таблице системных настроек не увидел site_url, manager_url.
                Пути в config.core.php прописаны верно, кэш сброшен… Я так понимаю эти значения устанавливаются после сброса кэша, так что значения должны быть нормальные.

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

                Вроде бы определил проблему:
                modx.pro
                В записях modx_session в конце не хватает «modx.mgr.user.config|a:0:{}», но решение из поста не помогает.
                  Fi1osof
                  16 января 2017, 14:42
                  +1
                  Да у вас там скорее всего редиректы какие-нибудь. Просто так ничего не бывает, смотрите какие коды отдают Ajax-запросы. Принудительная авторизация работает, значит уже ОК.
                    Олег
                    16 января 2017, 16:54
                    +1
                    Я решил не парить мозг, слишком много времени на это ушло.
                    Просто на поддомене установил modx, и потихоньку переношу таблицы из бд :)
                    Первый раз реально пригодилось, что практически вся информация лежит там.

                    Благодарю за помощь! Очень ценные советы.
                    Заодно получше разобрался в устройстве движка, какой-никакой, а плюс :)
                      Fi1osof
                      17 января 2017, 02:33
                      0
                      На здоровье!
                akkmeno
                31 июля 2017, 04:55
                1
                0
                Возникла такая же проблема при переносе на хостинг 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'] вообще не создаются.
                Дальше копать не стал почему они не создаются, так как надо, чтобы админка работала в понедельник.
                Однако проблему желательно решить нормальным способом, а не таким педальным как я выше привел))
                  Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
                  18