2 мая 2012 в 3:23
Доброго времени суток.
Пытаюсь перенести сайт с локальной машины на хостинг. Точнее перенес, но есть проблемы со входом в админку. У хостинга есть возможность захода на сайт по ихнему тестовому URL. Захожу по адресу [тестовый_адрес_сайта]/user для авторизации. ввожу логин и пароль и попадаю на страницу [тестовый_адрес_сайта]/users/[ник_пользователя] с элегантным и простым для понимания сообщением "Доступ запрещен / У вас нет доступа к этой странице".
Пытался восстановить пароль. При восстановлении на ящик падает письмо с одноразовой ссылкой для входа на сайт. Пробую войти и снова "нет доступа".
Проверяю на локальной версии на денвере - вход и выход работает.
Пробовал чистить кэш и куки браузера, чистил через phpmyadmin содержимое всех таблиц "cache*" и "sessions". толку никакого - снес и залил по новой - и снова "не алле". Предполагал, что проблема может быть в тестовом URL - ради любопытства заливал таким же макаром на соседнюю площадку разрабатываемый сайт на том же drupal7 и пробовал зайти - заходил...
Пытался проследить события лога. Рассматривал события в таблицах "accesslog", "sessions" и "watchdog". И выяснилась замечательная вещь - по ходу, сайт не пишет куки. В таблице "accesslog" каждое новое событие сопровождается сменой sid Browser session ID of user that visited page., чего не было на денвере. в таблице "sessions" ясно видно, что вводится верный логин и пароль - последние записи гласят, что при попытке входа открывается сессия для админа (uid=1), но при этом каждый раз новый sid A session ID. The value is generated by Drupal’s session handlers. Окончательным подтверждением того, что сессия успешно открыта является блиц-анализ последних записей таблицы "watchdog" - имеются упоминания, что "Session opened for %name." для юзера №1 и сразу же за ним идет запись "Access denied" для юзера №0.
Смею предположить, что при авторизации открывается сессия, но при этом браузеру не дается куки сессии и когда происходит редирект на страницу пользователя, друпал не находит инфы о сессии в куках и считает юзера обычным гостем и посылает его лесом.
Единственная кука от сайта, которая появляется сразу это has_js и все. На локальной же машине, при авторизованном пользователе, со всеми прибамбасами, висит 6 "печенек" в браузере.
Как победить данную оказию? Как заставить drupal7 писать куки?
Комментарии
можно попробовать в settings.php
session.cookie_lifetime 0 куки будут стираться по закрытию браузера
$cookie_domain = базовый домен -тут снять коментарий
но скорей всего второе
большое спасибо - второе помогло
Вот и у меня проблема.
После переустановки ПО на сервере на одном из сайтов появилась проблема со входом.
Отмечу, что в наличии ещё 5 Drupal сайтов на том же хосте, там всё нормально.
Авторизация, а далее:
Доступ запрещён
У вас нет доступа к этой странице.
Очищен кэш (через базу, все таблицы cache).
Очищен кэш браузеров.
испробован метод подстановки $cookie_domain, в том числе, и с лидирующей точкой.
Произведена смена пароля через базу UPDATE `users` SET `pass` = MD5('12345') WHERE `uid` =1;, но дело не в этом, т.к. пароль правильный.
В watchlog видно, что производится авторизация юзера с ID 1
1 user Session opened for %name. [BLOB - 30Байт] 5 http://site.ru/user
1 php %type: !message in %function (line %line of %file)... [BLOB - 274Байт] 5 http://site.ru/user
Потом редирект на профиль
0 access denied user/1 [BLOB - 2Байт] 4 http://site.ru/users/user_name
Уже с ID 0
ВременнАя последовательность не нарушена, timastamp ровненько последовательно.
Накатывал файлы последней версии.
Выкидывал директорию с модулями.
Ничего не помогло...
Угу, и логи читаете не с той стороны.
Из последнего
wid 16079
uid 1
type user
message Session opened for %name.
variables 613a313a7b733a353a22256e616d65223b733a353a2264656e6973223b7d
severity 5
location http://site.ru/user
referer http://site.ru/user
hostname x.x.x.x
timestamp 1344147022
wid 16080
uid 0
type access denied
message user/1
variables 4e3b
severity 4
location http://site.ru/users/admin
referer http://site.ru/user
hostname x.x.x.x
timestamp 1344147023
Вдохновляет.
Нашёл бэкап за май, там уже такая проблема. Неужели придётся кромсать сайт...
Уже долго-долго гуглю.
На http://drupal.org находится много топиков. Решения "для всех" нет. Какая-то неразрешённая проблема.
Перезалил все файлы из новой версии, бестолку.
Прочекал базу, норма. Дропнул sessions, импортировал со свежей инсталляции, не помогает. Но проблема видится здесь, в сессиях и куках.
Вижу лишь путь сравнения живой и ломанной баз, кручение переменных, что долго.
Либо сливать ноды и лепить новый сайт, что ещё дольше и печальнее.
Прошу не оставаться безучастными, это касается всех, ибо пороховая бочка. У меня руки из того места, в PHP смыслю, сервер сам поднимаю, поиском пользоваться умею. Как правило, нахожу решение любой проблемы, если оно есть в природе. Несколько сайтов работают, а один вот так сломался. Это значит, в любой момент может быть с любым. Был сайт и нету сайта, хотя он есть.
Ааааа!
Чьёрт... Убил несколько дней, перепахал весь сайт.
Совсем забыл, что недавно жёстко закешировал всё в nginx...
Поэтому и
-))