Подтвердить что ты не робот

Не удается войти в Magento Admin

У меня возникли проблемы с входом в панель администрирования Magento на одном из наших промежуточных сайтов (он работает на серверах webdev на 100% и отлично работает не так давно на промежуточном сервере).

Я провел некоторое исследование, и большинство людей полагают, что это связано с запуском Magento на локальном хосте, а браузеры не сохраняют файлы cookie для доменов без точек в доменном имени. Проблема с этим, однако, заключается в том, что мы запускаем его из http://staging.sitename... и т.д.

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

Есть ли у кого-нибудь идеи, которые могут помочь?

Спасибо, что нашли время, чтобы помочь мне!

С уважением,
Rémy

4b9b3361

Ответ 1

Мне удалось это исправить! Я нашел это решение здесь: http://blog.chapagain.com.np/magento-admin-login-problem/.

Я хотел знать, почему это исправлено, и var_dumped элементы, которые я прокомментировал, и понял, что для домена cookie установлено значение "/", и мы создали magento в разделе "/shop/". Поэтому я перешел в раздел конфигурации (после входа в систему после комментариев из 3-х строк, упомянутых в статье), изменил домен Cookie и Cookie Path на пустой и сохраненный. Затем я расколол эти строки и снова попытался, и все хорошо работает!

Ответ 2

В новой установке Magento сделайте следующее →

Откройте файл

app/code/core/Mage/Core/Model/Session/Abstract/Varien.php.

и измените код в строке 87 на это →

    $cookieParams = array(
        'lifetime' => $cookie->getLifetime(),
        'path'     => $cookie->getPath(),
      //  'domain'   => $cookie->getConfigDomain(),
      //  'secure'   => $cookie->isSecure(),
      //  'httponly' => $cookie->getHttponly()
    );

Ответ 3

Я также столкнулся с этой проблемой. Это то, что я сделал: В core_config_data удалите любые строки, где path = web/cookie/cookie_domain

Ответ 4

Просто очистите файлы cookie и кеш в веб-браузере. Он отлично работает для меня.

Ответ 5

Возможно, возникнет конкретная ошибка. Пару выстрелов в темноте -

Стоит проверить ваши перезаписи. У меня проблемы с сервером на сервер, где у одного из них нет правильной настройки перезаписи. если servername.com/index.php/admin работает, но servername.com/admin этого не делает, тогда у вас есть проблема с переписыванием.

Возможно также, что base_url не настроен для правильного сервера. Вы изменили его, когда переместили базу данных? Подробнее см. Мой ответ на этот пост.

Ответ 6

Я также столкнулся с этой проблемой. Это то, что я сделал: В core_config_data удалите все строки, где path = web/cookie/cookie_domain

Ответ 7

Привет, у меня была такая же проблема, и я решил ее, удалив все файлы в /var/session. Я думаю, это потому, что слишком много сеансов в Magento!

и для обеспечения безопасности я изменил "Использовать только HTTP" в "Нет" в "Управление cookie сеанса" настроек "Веб" после того, как я снова смогу loggin..

Я нашел это решение в Интернете: https://magento.stackexchange.com/questions/26071/magento-1-9-can-t-login-to-admin-panel

Ответ 8

Я решил просто очистить кеш (выполнить очистить кеш php mage из вашего базового каталога Magento

Ответ 9

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

Решение: каталог /magento/var/session был заполнен файлами сеанса sess_*, поэтому многие на самом деле пытались выполнить выполнение rm *. После утомительного взлома файлов сеансов по частям (rm sess_1*, rm sess_2*,... rm sess_a*, rm sess_b*,... rm sess_v*) я снова смог войти в Magento. На самом деле, я смог войти в систему после нескольких ударов.

Теория

Теория: когда в каталоге сеанса слишком много файлов, Magento, возможно, не сможет создать новые файлы сеанса своевременно или, может быть, совсем не работает.

Ответ 10

Я не могу получить доступ к бэкэнду!

(Решение для меня):

приложение/и т.д. /local.xml строка 55

    <session_save><![CDATA[files]]></session_save>

заменить

    <session_save><![CDATA[db]]></session_save>

Ответ 11

Если вы используете данные примера:

Изменение: приложение /etc/local.xml строка 55

<session_save><![CDATA[files]]></session_save>

заменить

<session_save><![CDATA[db]]></session_save>

Тогда: Очистить кеш браузера

Ответ 12

У нас была такая же проблема, и это было из-за нехватки места на жестком диске сервера. Magento не смог создать новую сессию и, следовательно, не смог бы войти в систему. Освободилось пространство, и проблема была решена.

Ответ 13

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

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

Измените пароль, и теперь вы можете снова войти в систему!

Привет

Ответ 14

Необходимо обновить 3 вещи в таблице core_config_data для следующих путей:

  • web/secure/base_url
  • web/unsecure/base_url
  • web/cookie/cookie_domain

используйте команды типа

UPDATE 'core_config_data' SET 'value'="localhost.com" WHERE path="web/cookie/cookie_domain"

и не забудьте очистить кеш и файлы cookie браузера.

Ответ 15

У меня была такая же проблема, и все это было с localhost.

Сначала я изменил web/unsecure/base_url и web/secure/base_url. Эти оба значения конфигурации имели localhost, а я заменил его на 127.0.0.1. Тем не менее он не работал, пока я не удалил все содержимое двух папок var/session/ и var/cache/.

Теперь он работает нормально.

Ответ 16

Я попытался решить эту проблему в нижней части страницы результатов поиска в гоголе. Я сделал все, что мог найти, что было предложено. Затем мой друг предложил этот инструмент командной строки n98-magerun. Запуск php n98-magerun.phar cache:flush решил. Тогда я мог бы войти в систему. Там есть множество команд, поэтому, если это не сработает, может быть, другая будет.

Ответ 17

После применения большого количества решений и ответов этот последний работал.

Комментировать строку 108 ~

call_user_func_array(’session_set_cookie_params’, $cookieParams);

в файле app/code/core/Mage/Core/Model/Session/Abstract/Varien.php

Ответ 18

Для чего стоит проверить, что поле пароля в admin_user не менее 100 символов.

Если это 40, смена пароля не будет работать.

Ответ 19

Я сделал простой метод. Я пошел в phpMyAdmin, а затем использовал новый пароль с хешем MD5. Затем успешно выполнил вход с этим паролем

Ответ 20

В моем случае папка session отсутствовала в папке var. Я просто создал папку var/session и установил разрешение на 777, очистил cache и сделал.

Вы должны проверить sysytem.log для этого.

Ответ 21

Очистка хранилища приложений из Chrome DevTools устранила эту проблему для меня.

Ответ 22

После выполнения всего этого, оставив все вышеупомянутые решения на месте, все еще никто из них не работал у меня. Я запускаю Win 7 + XAMPP и Magento Community magento-1.7.0.2

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

\ app\code\core\Mage\Admin\Model\User.php line 340

Из этого:

if ($sensitive && $this->getId() && Mage::helper('core')->validateHash($password, $this->getPassword())) {

Для этого:

if ($sensitive && $this->getId() || Mage::helper('core')->validateHash($password, $this->getPassword())) {

Так как это бокс dev, он останется необязательным для проверки хэшей паролей. Я полагаю,

ПРИМЕЧАНИЕ.. Не делайте этого в живой среде, пароли будут проходить каждый раз независимо от того, правильны они или нет, если ваше имя пользователя правильно.

По сути, этот код выполняет следующие действия: (username = correct или password = correct) {LOG IN} - Это означает, что если он пропустит имя пользователя, он будет записывать их.