Session ID regeneration does not work for concurrent requests
I posted this question on the CI forum but no answer, so I'm trying it here.
I am using CI for a REST API serving JSON calls from a single page application. With CI 2.x I had a problem with regenerating the session id in case of a "chain" of requests in a short time and some of them changed the session id. I was hoping CI 3 with its new session library would fix it.
I upgraded to 3.0, read the session docs carefully, and did some tests. From my point of view, the problem that occurred in CI 2.x still persists in version 3.0.
Let me explain this with an example of HTTP requests (actually observable from a real application):
The session id does not change:
GET ... Request cookies: ci_session=123,
Response cookies:
GET ... Request cookies: ci_session=123,
Response cookies:
...
The session ID should be restored:
GET ... Request cookies: ci_session=123,
Response cookies: ci_session: <deleted>, ci_session: 456
This request started earlier than the previous one, so it has the old session ID:
GET ... Request cookies: ci_session=123,
Response cookies:
But the session ID 123 is no longer valid, so the request is considered unauthenticated.
It seems that the lock added to the new session library is not preventing this.
My session config:
$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;
I am using session_write_close () after authenticating the original request.
Is there a way to use CI 3 for this king of requests? Am I doing something wrong? Any help is appreciated. Thanks you
source to share
Well, first of all, if you are using sessions, this is not a RESTful API, because the whole point of using a session is to maintain state, while a REST service must be stateless.
In this case, the parameter sess_regenerate_destroy
was created exactly for use, for example, yours. Set it to boolean FALSE and the old session ID will be garbage collected later, rather than immediately after being regenerated. This leaves a time window during which both old and new session IDs can be used and the queued request will not be denied.
source to share