CODEWITHSUNDEEP
phpajaxsessioncodeigniter-3
RastoStric
RastoStric

Reputation: 312

Session ID regeneration not working for concurrent requests

I had posted this question to the CI forum but without any answer so I am trying it here.

I am using CI for a REST API serving JSON calls from a single page app. With CI 2.x I had a problem with session ID regeneration in a case of "chain" of requests in a short time while some of them changed session ID. I hoped that CI 3 with its brand new session library will fix it.

I upgraded to 3.0, read carefully session docs and did some tests. From my point of view the problem which occured in CI 2.x is still persisting in 3.0.

Let me explain it on an example of http requests (actually observed from a real app):

Session ID is not changing:

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

Session ID is to be regenerated:

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

This request had started sooner than the previous one returned, so it is carrying the old session ID:

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

But the session ID 123 is not valid anymore so the request is regarded not authenticated.

It seems, that the locking, which was added to the new session library does not prevent this.

My session config is:

$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 initial request authentication.

Is there a way how to use CI 3 for this king of requests? Am I doing something wrong? Any help is appreciated. Thank you

Upvotes: 3

Views: 3072

Answers (1)

Narf
Narf

Reputation: 14752

Well, first of all - if you're using sessions, it's not a RESTful API, because the whole point of using a session is to maintain state, while a REST service must be stateless.

That being said, the sess_regenerate_destroy setting was created exactly for a use case like yours. Set it to boolean FALSE and the old session ID will be deleted later by the garbage collector instead of immediately upon regeneration. That leaves a time window during which both the old and the new session IDs are usable, and the queued request won't be rejected.

Upvotes: 2

Related Questions