Magento 1.9 Не могу войти в админку!

Я установил Magento 1.9 . Это работало хорошо в течение недели. Вдруг вчера, когда я попытался войти в панель администратора Magento и я напечатал usernameи password, нажал кнопку Вход и ничего не произошло. Страница обновляется и все. Нет ошибок или каких-либо других сообщений.

Если я ввел неправильное имя пользователя или пароль, это показывает ошибку.

После того, как я погуглил об этой проблеме, мне рекомендовали прокомментировать следующие строки в:

Приложение \ код \ ядро ​​\ Mage \ Ядро \ Model \ Session \ Аннотация \ Varien.php

/* to solve login issue */
  /*if (!$cookieParams['httponly']) {
  unset($cookieParams['httponly']);
  if (!$cookieParams['secure']) {
  unset($cookieParams['secure']);
  if (!$cookieParams['domain']) {
  unset($cookieParams['domain']);
  }
  }
  }

if (isset($cookieParams['domain'])) {
  $cookieParams['domain'] = $cookie->getDomain();*/ //I have commented these lines

А для некоторых более старых версий ниже был рекомендован тот же файл.

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

Даже после этого я не мог войти в админ. Это как было. Кто-нибудь сталкивался с этой проблемой? Есть ли другое решение этой проблемы?

(Я пробовал очистить кеш и сессию через ftp).

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

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

Возможные причины включают

• Время локального компьютера и время сервера не совпадают, что приводит к немедленной отмене cookie. Убедитесь, что время на вашем сервере правильное.

• Неправильные разрешения var/session, препятствующие сохранению файлов сеанса

• Неправильная конфигурация базы данных / redis / другого хранилища сеанса, препятствующая сохранению значений сеанса

• Модуль создает экземпляры сеансов на ранней стадии , предотвращая установку правильных имен сеансов

• Вы разработчик, использующий несколько URL-адресов и имеющий несколько доменов cookie

• Другой разработчик как-то модифицировал app\code\core\Mage\Core\Model\Session\Abstract\Varien.php, создав трудно выявляемую ошибку

• Домен cookie в System -> Configuration -> Web -> Session Cookie Managementне соответствует фактическому домену сайта.

• Вы используете localhostдомен своего сервера и используете версию webkit, в которой localhostв некоторых ситуациях возникают проблемы / ошибки при настройке файлов cookie .

Краткосрочное исправление состоит в том, чтобы просто удалить ваш файл cookie для домена. Этого достаточно, чтобы решить проблему. Если это не помогло, выясните, какая из приведенных выше причин является причиной вашей ошибки, и примите меры для ее устранения (исправьте разрешения и т. Д.)

У меня те же симптомы на некоторых установках Magento (не только 1.9). В моем случае это происходит только в Chrome. Я исправляю это, войдя в Firefox / Safari / Opera и изменив «Использовать только HTTP» на «Нет» в «Управление сессионными файлами cookie» в настройках «Веб».

У меня тоже была эта пробема. Полученные сеансы не могут быть записаны var/session, даже если сам каталог установлен в 0777. Magento создал файлы сессий, но все они остались нулевыми байтами.

Изменение памяти сеанса от filesдо dbрешена проблема для меня.

1. Откройте каталог установки Magento. Найдите и откройте файл index.php.
2. Поиск сообщения об ошибке (E_ALL | E_STRICT); код.

3. Прокомментируйте это так:

   /*error_reporting(E_ALL | E_STRICT);*/

4. И используйте вместо этого следующий код:

   error_reporting(E_ALL);

   $_SERVER['MAGE_IS_DEVELOPER_MODE'] = true;

5. Раскомментируйте его, удалив знак #, чтобы он выглядел так:

   ini_set('display_errors', 1);

6. Сохраните этот файл и загрузите на сервер. Перезагрузите страницу вашего сайта, чтобы увидеть ошибки.

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

У меня недостаточно репутации, чтобы комментировать, но @Alan Storm, может быть, вы хотите взять это в свой превосходный список.

У меня недавно была та же проблема, и у меня сработал простой трюк. Также это для людей, которые не могут получить доступ к панели инструментов в Google Chrome . Если вы можете работать с Mozilla Firefox, сделайте это, потому что я полагаю, что эта проблема не сохраняется в Mozilla Firefox.

Таким образом, решение для хрома:

Перейдите в Система-> Конфигурация-> Интернет . Разверните вкладку Небезопасный и безопасный . Измените базовый URL-адрес, http://127.0.0.1/[Your folder name]если вы используете localhost, или измените его на URL-адрес своего сайта, через который вы получаете доступ к веб-интерфейсу. Мне пришлось дважды войти в систему, чтобы попасть на панель инструментов, поскольку, когда я вводил данные в первый раз, она просто обновляется и возвращается на ту же страницу, на которой вы упомянули ее как зацикленную.

Откройте phpMyAdmin с вашего хоста, попробуйте один раз эту команду sql.

Запустите этот SQL:

SET FOREIGN_KEY_CHECKS=0;
UPDATE core_store SET store_id = 0 WHERE code='admin';
UPDATE core_store_group SET group_id = 0 WHERE name='Default';
UPDATE core_website SET website_id = 0 WHERE code='admin';
UPDATE customer_group SET customer_group_id = 0 WHERE customer_group_code='NOT LOGGED IN';SET FOREIGN_KEY_CHECKS=1;

Теперь администратор может войти в систему.

Пожалуйста, следуйте этому:

Страница администратора показывает 404 страницы не найдены

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

Список Alarm Storm является правильным и подробным. Вот пара дополнительных случаев.

1. В vagrant, проверьте разрешение var/sessionна хост-машине тоже
   (проблемы с монтажом)
2. Проверьте, заполнен ли ваш диск или слишком много файлов в var / session
3. Запустить n98-magerun.phar sys:check(ловит проблемы, включая cookie-домен)

4. Измените сеанс на базу данных, отредактировав local.xml. Это исключит большинство проблем с разрешениями при использовании insidie<global>

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

Также вы можете выбрать сторонние расширения (брандмауэр / расширения безопасности), например, https://github.com/paimpozhil/MageFirewall/blob/master/app/code/community/MageFirewall/Firewall/Model/Observer.php#L53 помещает вас в черный список, если вы пытаетесь слишком много раз.

Может произойти, если ваш сеанс изначально не работает для разрешения проблем, но затем продолжает сбой даже после устранения исходной проблемы

В вашем конкретном случае следите за admin_session_user_login_successсобытием, так как большинство модулей безопасности / брандмауэра используют это событие. Особенно следите, если переменная $_SESSION['admin']сбрасывается наблюдателями

Также важно, чтобы у вас был ключ формы, иначе ваша форма не будет обработана.

<?php echo $this->getBlockHtml('formkey'); ?>

Простое решение этой проблемы - использовать http://127.0.0.1 в качестве имени хоста вместо localhost.

Поскольку проблема заключается в том, что вы не можете войти в систему для своего администратора, вы должны изменить безопасные и незащищенные базовые URL-адреса в таблице базы данных: core_config_data

Это также будет проверять ваш baseurl с sys n98-magerun: check

Если вы разрабатываете localhostи задали или изменили свое доменное имя на localhost, обновите вместо него core_config_dataдоменные имена таблицы базы данных 127.0.0.1. НапримерUPDATE core_config_data SET value="http://127.0.0.1/magento/" WHERE path="web/unsecure/base_url";

Кроме того, вы можете обновить пароль в базе данных, если все остальное сверху не сработало и вам нужен отчаянный доступ:

UPDATE admin_user SET password=CONCAT(MD5('qXpassword'), ':qX') WHERE username=‘user’;

заменить слова пользователя и пароль в соответствии с вашими потребностями.

Прежде всего, попробуйте очистить ваш кеш, я думаю, и если это не работает, попробуйте сделать chmod 700 в вашей папке var.

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

То же самое случилось со мной некоторое время назад, и моя проблема возникла после сеанса. У меня не было достаточно места на диске для создания сеансов и кеша var/. Я удалил некоторые вещи, и все работало после. Может быть, это кому-то поможет.

ура

Попробуйте очистить кеш, опустошив папки «var / cache» и «var / session», это решило это для меня.

Я также должен был перезапустить веб-сервер после этого один раз.