Which session library to use? Any suggestions?

[eluser]shinokada[/eluser]
http://codeigniter.com/wiki/Category:Lib...::Session/

As you can see there are many session libraries. Can anyone give me recommendation or suggestions which library to use please?

Thanks in advance.

[eluser]BrianDHall[/eluser]
Personally, I just use the one that comes with CI. I save my sessions in the database and...well, that's it really. It does everything I could want, and I've yet to find it lacking.

Is there anything you find missing or problematic with the default session library?

[eluser]kurucu[/eluser]
Same attitude here - I find the CI one to cover all my bases, as well as being quick, easy to use and efficient.

What are your requirements for a session library, other than provide persistence of a session?

[eluser]garycocs[/eluser]
What's the deal with saving sessions in the database?? Maybe I'm getting sessions all wrong??

Thought you'd use a session to login, save the fact that's the user logged in that kinda thing??

[eluser]BrianDHall[/eluser]
[quote author="garycocs" date="1254538002"]What's the deal with saving sessions in the database?? Maybe I'm getting sessions all wrong??

Thought you'd use a session to login, save the fact that's the user logged in that kinda thing??[/quote]

Well for one, in a shared virtual server environment there are garbage collection issues. I don't know if it still exists to this day, but at least in the old days someone could set their php ini directive in a script and cause the server to garbage collect across all sessions - so your customer could be in the middle of checking out and someone else's script could cause their session to be destroyed. Yikes.

If that was fixed, as well as security vulnerabilities in your users sessions being able to be viewed by other scripts on the server, the more modern reason is for easy manipulation of current session info.

For instance, lets say you want to know in your script who is logged in and browsing your site in the last 10 minutes (like a "User's Online" in a forum) - try doing that with sessions that aren't stored in the DB.

Lets say you want to run a script hourly to check on abandoned shopping carts. How do you do that with non-database sessions?

In short if you want to interact with the sessions active on your web application as a whole, and not just the session of your active user, it is much harder to do with sessions that aren't saved in the database.

Coupled with security and "survivability" issues, these are just a few reasons why saving session info in the database is rather handy.

[eluser]InsiteFX[/eluser]
Amem

[eluser]garycocs[/eluser]
Thanks for that, it clears a few things up for me!! Bit of investigation for me to do!!

[eluser]Jondolar[/eluser]
Also, in some shared hosting environments, anyone that can view the /tmp direcotry (or the directory where sessions are stored) can view the content of every session variable that is active. This wouldn't be a problem if you encrypt your data prior to storing it in a session variable. Storing data in a session variable does take fewer resources on the server and may be quicker/easier to code (although I wouldn't use that as a criteria).

[eluser]mrbinky3000[/eluser]
[quote author="BrianDHall" date="1254266504"]Personally, I just use the one that comes with CI. I save my sessions in the database and...well, that's it really. It does everything I could want, and I've yet to find it lacking.

Is there anything you find missing or problematic with the default session library?[/quote]

HA! Lots!

I'm using the DX_AUTH authentication library to handle things like logging people in, and creating user accounts. It works fine on every browser out there except IE. It seems that the problem is with CI's default session management class.

I'm not the only one to notice this:
http://ellislab.com/forums/viewthread/115421/

This guy noticed this too:
http://bleakview.orgfree.com/obsession/

This guy wrote a session replacement library that forces CI to use PHP's native session management. Which is great except that DX_AUTH relies on the database portion CI's session management:
http://www.philsbury.co.uk/blog/code-igniter-sessions


So yeah, CI_session class. Unreliable.

[eluser]n0xie[/eluser]
[quote author="mrbinky3000" date="1258595096"]
So yeah, CI_session class. Unreliable.[/quote]
There is absolutely NOTHING wrong with the Session Class. There is a lot wrong with Microsoft's IE implementation of handling cookies, which is what the session class uses.

Usually when people claim the session library is unreliable, it's either because they read it somewhere or they don't know how the session library works.

For example let me disarm the points raised by your linked source. The fact that the article was written in 2008 and we are nearly in 2010 should set off some alarms at least:

1. Security : The User Data is stored in a cookie, client-side.
2. Security : The session is vulnerable to session fixation.
3. Usability : Enabling the session database does not actually store User-Data in the database!
4. Usability : Things like non-persistent sessions, flash variables and session id regeneration are not enabled.

Point 1.
This can be altered by using encrypted cookies. Not everyone stores private data into a session, hence no need to encrypt it by default. This is called flexibility and is, at least in my book, a feature.

Point 2.
No it's not. The session gets regenerated.

Point 3.
Unless the field user_data is missing in the database, I don't see how one could argue this.

Point 4.
Yes they are and they are documented.


So what causes all these strange session behaviours? Well the clue should be that it only occurs in IE. Hence I put a link in my footer so everyone could read what was causing it! Isn't that convenient. So next time when you make a claim about the session library, you should probably first click the link in my footer, read it, understand its implications, then go harass your local Microsoft representative and ask him if it's REALLY that hard for them to comply to ANY form of standard.