Я не могу войти после миграции

9

Я искал что-то вроде сотен решений и реализовал их все. Я также искал этот сайт, чтобы найти тот же вопрос, но я не смог его найти.

У меня есть сайт разработки и производственный сайт. Для перехода между ними я использую github push и pull. Это не было проблемой в прошлом, однако я сталкивался с этой проблемой несколько раз. После миграции файлов Drupal больше не позволяет мне войти в систему. Я пытаюсь ввести свои учетные данные и сразу получаю страницу «Отказано в доступе».

Файлы cookie моего сайта читают и пишут без проблем. Я нашел идентификатор куки и нашел его запись в базе данных. Таким образом, файлы cookie работают нормально, а записи в базе данных работают нормально.

Проблема, которую я вижу, состоит в том, что записи сеанса базы данных не сохраняют идентификаторы пользователей. Когда я вручную изменяю идентификатор пользователя в записи базы данных на 1 для моего IP, а затем обновляю веб-сайт, я захожу в систему. Есть идеи?

/programming/2846935/cannot-login-to-drupal-in-chrome-or-firefox-but-safari-works предлагает мне обновить $ cookie_domain в файле settings.php. Я перепробовал каждую конфигурацию, и это не помогло.
http://www.go2linux.org/cannot-login-into-drupal-table-corrupted также предлагают мне восстановить таблицу сеансов. Я сделал это, очистил сессии от БД и очистил мои куки. Это не работает.
http://www.madebymorgan.com/blog/2010/07/15/cant-login-after-drupal-617-upgrade предлагает мне обновить значения в моем файле settings.php: $ cookie_domain и $ base_url. Я перепробовал каждую комбинацию и потерпел неудачу.
Я прочитал INSTALL.txt , который говорит , чтобы выполнить следующие команды для соответствующих уровней разрешений и собственности: chmod o+w sites/default/settings.php, chmod o+w sites/default, chmod o+w sites/default/files, chmod a-w sites/default/settings.php, chmod a-w sites/default. Это не сработало.
Патч в http://drupal.org/node/56357#comment-236726 добавляет некоторый код в ваш файл сессий. Я сделал это, и это не сработало.
На http://drupal.org/node/56357#comment-391535 замечательно подойдет markus_petrux, определив PHPSESSID с новым именем, а также установив домен и путь файла cookie вручную. Это не сработало.
http://old.nabble.com/Re%3A-Can%27t-login-p22258960.html предлагает добавить register_shutdown_function('session_write_close');в конце работы settings.php, что также не работает для меня.
http://drupal.org/node/6696#comment-204863 говорит нам, чтобы добавить некоторые настройки ini в файл settings.php, очистить кеш, очистить файлы cookie, очистить конфиденциальность, перезапустить Firefox и добавить в settings.php следующие строки:

ini_set('session.cookie_domain', 'exampleorg');
ini_set('session.cookie_domain','www.example.org');
ini_set('session.auto_start', 0);

— Консультант по электронной коммерции
источник

Просто сделал небольшое открытие здесь. Мой сайт продолжает переключаться между HTTPS и HTTP во время входа в систему. Так что мне интересно, если это скинуть сессию.

— Консультант по электронной коммерции

Боже мой, я нашел мою проблему. Я неправильно настроил свой виртуальный хост для моего SSL. Мой SSL указывал на мой сайт разработчика, а не на мой живой сайт. Так что тот факт, что он перенаправлял меня после входа в систему, означал, что я полностью менял сайты. это было ужасно ... забрал меня весь день ..

— Консультант по электронной коммерции

6

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

sudo a2enmod rewrite

— Елин Й.
источник

Иногда это самые простые решения. Спасибо!

— mcriecken

3

К вашему сведению, ваш сайт sites \ default \ settings.php должен содержать файл cookie с тем же именем, что и используемый вами путь, поэтому, если ваш предыдущий веб-сервер имел домен www.boldlygowherenomanhasgonebefore.com, и вы переместили ваш drupal в localhost, cookie домен должен отражать это изменение:

БЫЛО: $cookie_domain = '.boldlygowherenomanhasgonebefore.com';
ИЗМЕНИТЬ В: $cookie_domain = '.localhost';

— Брэндон Феррара
источник

Вы выиграли :) Это именно то, что я сделал

— qasimzee

1

Очевидно, не ваше решение, но для всех, кто сюда зашел, у меня была похожая проблема (не удалось войти в систему), но у меня была проблема с чистыми URL-адресами, решаемая следующим образом:

Что-то происходило с чистыми URL-адресами, они были полу-работающими, поэтому я отклонил их как проблему, но это было так.

В конце концов мне пришлось отредактировать таблицу переменных в БД (изменив LONGBLOB на LONGTEXT, чтобы я мог), отключив флаг очистки URL-адресов (установите «1» в «0»), очистить кеши для удаления кэшированной версии переменных.

И тогда все заработало правильно.

— Adaddinsane
источник

0

Не то чтобы это решило корень проблемы, но если вам нужно войти в систему, вы всегда можете получить одноразовую ссылку для входа в систему от Drush:

drush user-login theusername

— Ханс Россель
источник