Разлогинивает рандомно + доступ к логину за пределами форума

[rxu]

попробую написать на phpbb.com.

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

[BadBlock]

Например, можно подумать над тем, чтобы ключ после использования помещался в спецтаблицу с указанием sid новой сессии, и очень коротким временем жизни, типа 1 минута.

В этом случае во втором запросе из моего сценария (протухший sid и невалидный ключ) можно просто проверить эту таблицу, и если ключ k1 в ней есть, то игнорировать sid1 из куки, взять данные новой сессии для ключа k1 из этой таблицы и не создавать новую сессию sid3, а применить имеющуюся sid2, повторно отправив в браузер обновлённые куки c sid2 и k2. Юзер останется залогиненным.

Отправлено спустя 8 минут 28 секунд:

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

Полагаю, алгоритм воспроизведения может быть такой:
1. Установить в админке время жизни сессии 10 минут.
2. Зайти на форум с включённой галкой "Запомнить меня". Оставить открытой главную страницу.
3. Подождать 15 минут.
4. Зажав кнопку Ctrl, быстро (в пределах секунды) щёлкнуть по паре разделов форума.
По идее, должно разлогинить, особенно если пинги большие.

[rxu]

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

Отправлено спустя 21 секунду:

Полагаю, алгоритм воспроизведения может быть такой:

Проверьте.

[BadBlock]

Сессии в принципе отвязаны от ключей автовхода.

Нет. Именно привязаны.
Ключ генерируется из sid сессии. Стартует новая сессия — сразу для неё, и c использованием её sid, генерируется новый ключ автовхода.
Сессия протухла — используется ключ, но тут же стартует новая сессия и генерируется новый ключ автовхода.

Проверьте.

Проверю на досуге, да.

[rxu]

Сессия протухла — используется ключ, но тут же стартует новая сессия и генерируется новый ключ автовхода.

Тогда автовход должен происходить без проблем.

[Siava]

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

Юзер после долгого отсутствия на форуме открывает сразу 2 его страницы. Понимаете? Сразу, параллельно.
Первая страница создаёт сессию и автозалогинивает юзера. Она генерирует новый sid и ключ.
Вторая тут же разлогинивает

Всё именно так! Причём неважно в каком браузере, но по моим наблюдениям почему-то в хроме больше вероятность такого разлогинивания.. возможно потому что он при запуске открывает все вкладки, тогда как другие фоновые держат закрытыми.
И в логе connection log появляется сначала запись, что авторизация была с автовходом, но сессия уже тю-тю.

[BadBlock]

Тогда автовход должен происходить без проблем.

Так он и происходит, но только для первого запроса.
А на втором запросе с тем же sid и k — юзера разлогинивает.
Механизм разлогинивания описал максимально подробно.

Отправлено спустя 1 минуту 56 секунд:

возможно потому что он при запуске открывает все вкладки, тогда как другие фоновые держат закрытыми.

О! Тоже вариант. Восстановление вкладок же.

[rxu]

Так он и происходит, но только для первого запроса.

Это нонсенс. После первого запроса и куки, и ключ обновляются. Второй запрос в том же браузере пройдет без проблем. Старой куке и ключу взяться неоткуда.

[BadBlock]

Это нонсенс. После первого запроса и куки, и ключ обновляются. Второй запрос в том же браузере пройдет без проблем. Старой куке и ключу взяться неоткуда.

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

Но если второй запрос выполняется ДО получения обновлённых кук из первого запроса, то он отправляет старые куки. К моменту поступления второго запроса на сервер старые куки уже обе невалидны, и юзер получает гостевую сессию.

Отправлено спустя 30 минут 53 секунды:
Посмотрел в БД.
Автологиновые сессии можно прекрасно отличить от обычных по полю session_autologin (0 или 1).

Таким образом, временное решение проблемы "на коленке" представляется следующим:

1. По умолчанию время жизни сессии, если не ошибаюсь, 1 час.
2. Установить в админке очень большое время жизни сессии. Типа там, не знаю, дни или месяцы.
3. Написать свой маленький крон-скрипт, который будет ходить и прибивать сессии c полем session_autologin = 0, последняя активность у которых была более 1 часа назад.

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

А автологиновые сессии не будут умирать очень долго. Для регулярных юзеров вообще никогда.

По-моему, должно быть достаточно эффективно.

[Siava]

Установить в админке очень большое время жизни сессии. Типа там, не знаю, дни или месяцы.

А что будет, если за это время у пользователя сменится IP адрес, версия браузера? Данные в сессии останутся прежние? Я честно не помню как там всё работает, но при смене IP, версии браузера сессия создавалась новая.

[Pazh]

Если в Chrome зайти в панель разработчика и там переключить на мобильный вид (Togle device toolbar) и обновить страницу - происходит разлогирование если не было включено запоминание при входе в аккаунт.

[Siava]

Pazh, вероятно потому, что user-agent меняется.

[Sheer]

Pazh, там в этом случае меняется сессия браузера, со всеми вытекающими последствиями. За это Хром не люблю и им не пользуюсь при разработке.

[BadBlock]

Pazh, там в этом случае меняется сессия браузера, со всеми вытекающими последствиями. За это Хром не люблю и им не пользуюсь при разработке.

При разработке можно и отключить проверку браузера в админке. Зачем эта проверка на dev-инсталляции?

А что будет, если за это время у пользователя сменится IP адрес, версия браузера? Данные в сессии останутся прежние? Я честно не помню как там всё работает, но при смене IP, версии браузера сессия создавалась новая.

Это зависит от настроек на странице "Безопасность" в админке ( adm/index.php?i=acp_board&mode=security ).
Если изменилось то, что там включено — сработает ключ автологина, создастся новая сессия и новый ключ — всё, как сейчас, ничего не поменяется.
Вероятность того, что при этом ещё и на сервер от клиента полетят два параллельных запроса, и сейчас невелика, а тут ещё уменьшится на порядки.

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

Более корректным и долговременным решением видится что-то типа того, что я описал выше, это решение должно принципиально снять проблему разлогинивания по невалидным кукам как таковую. Но это решение требует:
1. Изменений в коде ядра.
2. Добавления новой таблицы в БД или же модификации имеющейся таблицы session_keys — например, добавить в неё 2 новых поля: "предыдущее значение ключа" и "timestamp изменения значения ключа".

Алгоритм: некоторое короткое время после изменения значения на новое (несколько секунд, не более минуты) считаем предыдущее значение протухшего ключа валидным. В пределах этого времени при поступлении запроса со старым ключом применяем соответствующую старому значению новую залогиненную сессию и новое значение ключа и возвращаем в куках. Юзер остаётся залогиненным.

[BadBlock]

Написал небольшое расширение — решение "на коленке".
Решение чистое: код ядра не трогается, системные таблицы не меняются.

Как им пользоваться:
1. Выставить в админке, на странице "Общие" - "Нагрузка на сервер", большое время жизни сессии (я у себя поставил пока 30 дней, то есть, 2592000 секунд).
2. Установить расширение.
3. В настройках расширения выставить небольшое время жизни сессии — я у себя поставил 1 час, то есть, 3600 секунд.
4. Это всё.

Что происходит:

- Расширение по крону чистит протухшие сессии — старше, чем, к примеру, 1 час. Но оно чистит только сессии гостей и обычные (неавтологиновые) сессии юзеров. Автологиновые сессии и ключи не трогает вообще.
- Автологиновые сессии, если они протухают, через 30 дней снесёт системный крон (функция session_gc()). Системный крон будет также пытаться продолжать чистить обычные сессии + гостевые, тут ничего не меняется, но они до этого крона уже просто не доживают, т.к. 30 дней не живут. Также системный крон продолжает чистить протухшие ключи автологина.

Что это даёт:

Вылет автологиновых сессий по описанному сценарию происходит у юзеров, которые после протухания сессии сразу открывают несколько страниц за раз (восстановление вкладок, менеджер сессий в браузере, просто быстро тыкают и пр.). Так действовать может только наиболее активный "костяк" форума, доставлять неприятности которому хочется меньше всего. Если они ставят галку "запомнить меня", нужно сделать всё, чтобы оно работало.

Указанная выше настройка времени жизни сессий даёт тот эффект, что автологиновые сессии для активных юзеров не протухают в течение 1 месяца (разумеется, в зависимости от настройки) — а значит, каждый день новая сессия не создаётся, т. к. юзер попадает всё время в свою предыдущую залогиненную сессию, и сценарий разлогинивания не срабатывает.

При этом моё расширение берёт на себя очистку обычных (неавтологиновых) сессий и гостевых сессий, не давая таблице сессий разбухнуть в результате выставления слишком большого времени жизни сессии.

Если интересно, сообщите — дотестирую и, если всё нормально, приложу код.