Я разместил этот вопрос на форуме 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 для этого короля запросов? Я делаю что-то неправильно?
Любая помощь приветствуется.
Спасибо
Ну, во-первых, если вы используете сеансы, это не API RESTful, потому что весь смысл использования сеанса заключается в поддержании состояния, в то время как служба REST должна быть без сохранения состояния.
Как говорится, sess_regenerate_destroy
Настройка была создана именно для такого варианта использования, как ваш. Задайте для него логическое значение FALSE, и старый идентификатор сеанса будет позже удален сборщиком мусора, а не сразу после регенерации. Это оставляет временное окно, в течение которого можно использовать как старый, так и новый идентификаторы сеанса, и запрос в очереди не будет отклонен.
Других решений пока нет …