Регенерация сеанса вызывает истекший сеанс с быстрыми вызовами AJAX

Во-первых, предложенное вами решение вполне разумно. Фактически, сотрудники OSWAP советуют именно это:

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

К сожалению, это невозможно реализовать с помощью стандартного управления сеансами PHP (или я не знаю, как это сделать). Тем не менее, реализация этого поведения в пользовательском драйвере сеанса ¹ не должно создавать серьезных проблем.

Теперь я собираюсь сделать смелое заявление: вся идея периодической регенерации идентификатора сеанса нарушена. Теперь не поймите меня неправильно, повторно генерируя идентификатор сеанса при входе в систему (или, точнее, as По словам OSWAP, «изменение уровня привилегий») действительно является очень хорошей защитой от фиксация сеанса.

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

Есть лучшая (и более простая) защита от простой кражи сеанса: используйте SSL (HTTPS). Периодическое обновление сеанса следует рассматривать как обходной путь для этого вектора атаки.

¹ ссылка на стандартный путь PHP

ваша проблема, похоже, меньше связана с фактической скоростью запросов (хотя это и является фактором), а больше с параллелизмом. Если я правильно понимаю, ваше приложение javascript делает много (асинхронных) вызовов ajax - быстро (предположительно, в пакетах) - и иногда некоторые из них терпят неудачу из-за аннулирования сеанса из-за того, что вы считаете проблемой скорости запросов. Ну, я думаю, что проблема в том, что у вас на самом деле есть несколько одновременных запросов к серверу, в то время как у первого сеанс обновлен, а другой по существу не может его увидеть, потому что запрос уже сделан и ожидает обработки сервером.

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

Теперь реальный вопрос здесь - что в вашем приложении требует бизнес-логика для этого?

Мне кажется, что вы пытаетесь найти техническое решение «деловой» проблемы. Я имею в виду, что либо вы неправильно истолковали свои требования, либо требования просто не так хорошо продуманы/указанны.

Я бы посоветовал вам попробовать что-то из следующего:

• спросите себя, можно ли объединить эти несколько одновременных запросов в один

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

• каждый раз, прежде чем вы запускаете серию запросов, запускайте «обновляющий» запрос ajax, чтобы получить новый сеанс, и только в случае успеха продолжайте выполнять все остальные запросы.

Надеюсь, что-то из того, что я написал, поможет вам найти решение. Удачи