[El Forum]

[eluser]Silviu[/eluser]
Well, I plan to have quite some AJAX in my app...

LE:

What the risk about storing the user ID in a native PHP session? Won't this solve all my issues?

[El Forum]

[eluser]WanWizard[/eluser]
NO.

Native PHP sessions are NOT secure!

If you would opt to use the third party CI implementation of (what's imho wrongly called) native sessions, it uses the same cookie mechanism as the CI library, so all above applies. And since the ajax issue is related to how the session id is rotated, this implementation suffers from the same issues as well.

In the backend however, PHP stores it's session in shared file space on disk, in a plain serialized array, with read/write access by your web server. So any application can access the session data without any difficultly. Securing this is not for the faint harted.

[El Forum]

[eluser]Silviu[/eluser]
Then how can I handle the session rotation "issue" in regards of AJAX?

This seems to be the last "nail in the coffin" :-)

[El Forum]

[eluser]WanWizard[/eluser]
Do a search for "is_ajax" and "sess_write", it has been discussed a lot in the past.

[El Forum]

[eluser]Silviu[/eluser]
I am doing that now.

Isn't this "issue" important enough to warrant a page in the wiki/knowledge base somewhere?

LE:

Found something: http://ellislab.com/forums/viewthread/138823

Question:
Since I haven't felt the need to extend CI so far in any way, what is written in that thread (the two steps) is the only thing needed to be done? Meaning that afterwards i need to do nothing special in my app, just use the session class as before? No special declaration or something needed?

[El Forum]

[eluser]WanWizard[/eluser]
Yes. Basically you need something that detects the ajax call, and you need to bypass the update call if it's an ajax call to prevent rotation.

Extending should be transparent for the application calling the class, providing the API doesn't change (which is the case here).

[El Forum]

[eluser]Silviu[/eluser]
Ok, got it.

Thanks everyone for your helpful answers.

Regards, S.

[El Forum]

[eluser]pickupman[/eluser]
In addition another method to Wanwizard's session library, which I am using, it also posted on [url="https://bitbucket.org/ellislab/codeigniter-reactor/issue/262/rapid-requests-during-session-updates"]Reactor Ticket#262[/url]. I linked the same thread, but another simple fix can be done to prevent session rotation during AJAX requests.

[El Forum]

[eluser]Jaketoolson[/eluser]
I'd like to echo what everyone has suggested thus far. I've always stored a unique_id to each user in the DB. When querying the user_db, I reference this unique_id rather than the auto_increment value or anything else. Users are hashes in my queries, not people!

Why not create a MySQL table which utilizes the MEMORY storage engine? It's 30% faster than myisam and 50% faster than innodb. Downsides to MEMORY? If the DB goes down, everything in tables using MEMORY engine is dumped but this is why it's good for storing session data. And lets be honest, if the db goes down or offline randomly, session data is the least of your concerns.
http://dev.mysql.com/doc/refman/5.0/en/m...ngine.html

HTML 5 finally has local storage - better than cookies in that they are easier to iterate through and utilize.
http://diveintohtml5.org/storage.html