Им будет нужен алгоритм повторения данного бага, которого пока нет.
Может быть, возможно создать искусственные условия, при которых он будет надежно воспроизводиться.
Может быть, поиграть с настройкой времени действия автовхода.
Им будет нужен алгоритм повторения данного бага, которого пока нет.
k1
в ней есть, то игнорировать sid1
из куки, взять данные новой сессии для ключа k1
из этой таблицы и не создавать новую сессию sid3
, а применить имеющуюся sid2
, повторно отправив в браузер обновлённые куки c sid2
и k2
. Юзер останется залогиненным.Полагаю, алгоритм воспроизведения может быть такой:
Проверьте.
Нет. Именно привязаны.
Проверю на досуге, да.
Тогда автовход должен происходить без проблем.
BadBlock писал(а): ↑01.06.2019 8:14 утром человек открывает форум, и не обязательно открывает главную страницу сайта и форум параллельно, а может просто из сохраненных закладок открывать в нескольких вкладках браузера несколько подфорумов. Сразу, параллельно. Первая вкладка открывается нормально, в друх других авторизация слетает.
Всё именно так! Причём неважно в каком браузере, но по моим наблюдениям почему-то в хроме больше вероятность такого разлогинивания.. возможно потому что он при запуске открывает все вкладки, тогда как другие фоновые держат закрытыми.
Так он и происходит, но только для первого запроса.
О! Тоже вариант. Восстановление вкладок же.
Это нонсенс. После первого запроса и куки, и ключ обновляются. Второй запрос в том же браузере пройдет без проблем. Старой куке и ключу взяться неоткуда.
Второй и последующие запросы в браузере пройдут без проблем только в том случае, если они выполнены после получения с сервера данных первого запроса, а именно новых кук.
session_autologin
(0 или 1).session_autologin = 0
, последняя активность у которых была более 1 часа назад.А что будет, если за это время у пользователя сменится IP адрес, версия браузера? Данные в сессии останутся прежние? Я честно не помню как там всё работает, но при смене IP, версии браузера сессия создавалась новая.
При разработке можно и отключить проверку браузера в админке. Зачем эта проверка на dev-инсталляции?
Это зависит от настроек на странице "Безопасность" в админке (
adm/index.php?i=acp_board&mode=security
).session_keys
— например, добавить в неё 2 новых поля: "предыдущее значение ключа" и "timestamp изменения значения ключа".session_gc()
). Системный крон будет также пытаться продолжать чистить обычные сессии + гостевые, тут ничего не меняется, но они до этого крона уже просто не доживают, т.к. 30 дней не живут. Также системный крон продолжает чистить протухшие ключи автологина.