Регенерация идентификатора сеанса не работает для одновременных запросов

Я разместил этот вопрос на форуме CI, но без какого-либо ответа, поэтому я пытаюсь его здесь.

Я использую CI для REST API, обслуживающего вызовы JSON из одностраничного приложения.
С CI 2.x у меня была проблема с регенерацией идентификатора сеанса в случае «цепочки» запросов за короткое время, в то время как некоторые из них меняли идентификатор сеанса. Я надеялся, что CI 3 с его новой библиотекой сессий исправит это.

Я обновился до 3.0, внимательно прочитал сессионную документацию и провел несколько тестов. С моей точки зрения, проблема, возникшая в CI 2.x, все еще сохраняется в 3.0.

Позвольте мне объяснить это на примере http-запросов (фактически наблюдаемых в реальном приложении):

Идентификатор сеанса не меняется:

GET ... Request cookies: ci_session=123,
Response cookies:
GET ... Request cookies: ci_session=123,
Response cookies:
...

Идентификатор сеанса должен быть восстановлен:

GET ... Request cookies: ci_session=123,
Response cookies: ci_session: <deleted>, ci_session: 456

Этот запрос был запущен раньше, чем предыдущий, поэтому он переносит старый идентификатор сеанса:

GET ... Request cookies: ci_session=123,
Response cookies:

Но идентификатор 123 сеанса больше недействителен, поэтому запрос считается не прошедшим проверку подлинности.

Кажется, что блокировка, которая была добавлена ​​в новую библиотеку сессий, не предотвращает это.

Моя сессия конфигурации:

$config['sess_driver'] = 'files';
$config['sess_cookie_name'] = 'ci_session';
$config['sess_expiration'] = 7200;
$config['sess_save_path'] = <some path>
$config['sess_match_ip'] = FALSE;
$config['sess_time_to_update'] = 60;
$config['sess_regenerate_destroy'] = TRUE;

Я использую session_write_close () после первоначальной аутентификации запроса.

Есть ли способ, как использовать CI 3 для этого короля запросов? Я делаю что-то неправильно?
Любая помощь приветствуется.
Спасибо

3

Решение

Ну, во-первых, если вы используете сеансы, это не API RESTful, потому что весь смысл использования сеанса заключается в поддержании состояния, в то время как служба REST должна быть без сохранения состояния.

Как говорится, sess_regenerate_destroy Настройка была создана именно для такого варианта использования, как ваш. Задайте для него логическое значение FALSE, и старый идентификатор сеанса будет позже удален сборщиком мусора, а не сразу после регенерации. Это оставляет временное окно, в течение которого можно использовать как старый, так и новый идентификаторы сеанса, и запрос в очереди не будет отклонен.

2

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]