3

我已将这个问题发布到 CI 论坛但没有任何答案，所以我在这里尝试。

我正在将 CI 用于提供来自单页应用程序的 JSON 调用的 REST API。在 CI 2.x 中，在短时间内请求“链”的情况下，会话 ID 重新生成存在问题，而其中一些请求更改了会话 ID。我希望 CI 3 及其全新的会话库能够修复它。

我升级到 3.0，仔细阅读会话文档并做了一些测试。从我的角度来看，CI 2.x 中出现的问题在 3.0 中仍然存在。

让我通过一个http请求的例子来解释一下（实际上是从一个真实的应用程序中观察到的）：

会话 ID 不变：

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

会话 ID 将被重新生成：

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

这个请求比前一个返回的请求开始得早，所以它带有旧的会话 ID：

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

但是会话 ID 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 用于这个请求之王？难道我做错了什么？任何帮助表示赞赏。谢谢

4

1 回答 1

2

好吧，首先 - 如果您使用会话，它不是 RESTful API，因为使用会话的全部意义在于维护状态，而 REST 服务必须是无状态的。

话虽如此，该sess_regenerate_destroy设置是为像您这样的用例而创建的。将其设置为布尔值 FALSE，旧的会话 ID 将在稍后被垃圾收集器删除，而不是在重新生成时立即删除。这留下了一个时间窗口，在此期间旧会话 ID 和新会话 ID 都可用，并且排队的请求不会被拒绝。

于 2015-05-13T11:21:05.933 回答