DerekAllard.com

Enhanced CodeIgniter Session library

A week ago (August 9th) we quietly added some nice enhancements to the CodeIgniter Session library that I wanted to mention.  You can see these for yourself in the subversion repository (here’s the Session.php library and the userguide page).  The upgrades will be part of the next CodeIgniter release.  Three notables include (in descending order of sexiness):

Configurable time_to_update variable

$time_to_update was a variable hardcoded to 300 (5 minutes in seconds).  After the time to live expired, the CI session class runs sess_update, which does some general maintenance and session handiwork.  While 5 minutes is probably a very good choice for 99% of us, there may be times when you want the update to run faster or slower.  So the update time is now configurable by adding $config[‘sess_time_to_update’] to your config file with the rest of the session preferences.  If you choose not to add it, CI just assumes 5 minutes for you.

Regenerating Session Ids

When a session is created, CodeIgniter (well, all PHP applications really) creates a “session id” and assigns it uniquely to you.  In this manner, data can be exchanged with you without also giving away your session data to other visitors.  CodeIgniter now regenerates your id every time sess_update runs (this is of course what makes the configurable time noteworthy). This provides an additional layer of protection against session fixation.

Flashdata variables

OK, now on to the most impressive addition - Flashdata.  Flashdata are variables that only exist for the next request.  They are mostly useful for “flashing” messages like The person $person was successfully edited, but can extraordinarily useful in the general development of a web application.  In Bamboo I use them to indicate success or failure messages to the user, store whom was edited for dynamic dropdowns, store a client name for assigning of invoices, and other various purposes.  Again… very useful.

Using them is almost the same as using the current session library.

$this->session->set_flashdata('foo', 'bar'); // a variable that only exists for 1 request
$this->session->flashdata('foo'); // reading a flashdata variable 

There is also a keep_flashdata() function, should you need to preserve from one request to another, perhaps a redirect.

If you’ve used any of the wonderful third party CodeIgniter session libraries, you’ve probably already enjoyed some of these features, and I suspect they will be a welcome addition to your toolkit.  On that note though, I’d like to personally take a moment to thank some of the people who have already done great work in this area. Thanks Dariusz Debowczyk (native session), Oscar Bajner (OBsession), Monte Ohrt ( PHP Session), and Dready (DB Session) for their fine work in this area.

This was not an attempt to re-write the session library, but rather to add in a few commonly requested and useful features.  Enjoy!, and I hope it takes your programming to even higher heights!

This entry was made on and filed into CodeIgniter.

Comments

Yannick wrote on

Cool thanks for the little intro to what’s to come in CI. The flashdata variables could be very very useful and I like the idea of the regenerating session ids.

Keep up the good work.

Torok Alpar wrote on

Hy, this is really great what you have done! I am pretty young, and don’t have a massive experience, but have learned some thing on security, i find managing sessions trough a database (there are some that don’t need it, i agree) is a better alternative, so i wrote some code myself to do just that, i have a very rough version in a page at the CI wiki with some very basic explanations (i actually modified the existing one). I can see that you are a much more experienced person than me, so i would deeply appreciate it if you cold make the effort of taking a look and giving me some feedback on it. Thank you

Jon wrote on

Ahhh…but are cookies really the best way to go?  I’ve seen tons of arguments on the CI forums regarding the benefits/drawbacks of using cookies.  What’s your take?

Derek wrote on

I think its the responsibility of the application programmer to know the needs of their software.

In the world of software, there is no 1 size fit all solution.  I think the CodeIgniter session library is incredibly useful.

I’m not sure I understand the depth of your question though. How would you propose to implement sessions without using cookies of some variety?

Jon wrote on

Good answer :)

I’ve always been curious why CI seems to have (intentionally) ignored the built-in PHP session functionality by using cookies vs. session.  While I agree that most data stored in the cookie is typically superfluous (sp?), there are instances where the 4KB limit can be a hindrance.

What I’m wondering is why CI went with cookies in the first place.  Is it faster?  Is it more reliable?  Is it “better” for what CI does?

Before I starting using CI, I was always a user of the PHP’s built-in session handler.  The sole purpose of the cookie is to store the sessionID.

The engineers at Yahoo published an article with regards to cookies and their impact on speed and performance:
Article
In a nutshell, cookies cause a performance hit the bigger they get; which can be a concern if your website is serving lots of visitors.

So, basically, I’m curious what your opinion is with regards to using the cookie approach versus the built-in php session approach vs “other” approaches (database, etc).

Personally, I prefer the native PHP session because it’s native, PHP handles the garbage collection, and there’s only a small cookie needed to maintain state.  In the case where cookies are disabled (which I’ve encountered more times than I can count), I can always pass the session id in the URL to maintain state. (doesn’t prevent session fixation unless you combine the solution with IP matching or something).

Derek wrote on

CI originally implemented its own session solution because of the wildly inconsistent way various servers handled cookies.

Note: The Session class does not utilize native PHP sessions. It generates its own session data, offering more flexibility for developers.

If you want to use native sessions, I’d encourage you to check out native session which I really liked, and used in Bamboo for a long time.  The problem here was the number of support emails I started getting for people whose servers were running in safe-mode.  This convinced me to revert back to the CI way of handling things.

I don’t deny for a minute that there are drawbacks to storing large cookies, or that storing on the server side has advantages.  This is something I’m looking at for future versions of the library, but for now, if you wanted to take advantage of various features not offered in the CI session, you could use one of the many excellent alternative libraries I’ve listed above ;)

Its true that CI-based sessions are not going to work for every developers needs.

K_R wrote on

Now the final question is - when is CI 1.5.5 going to be released?

Scott wrote on

I am using CI for sensitive session data and I didn’t feel comfortable storing that info in a cookie, even if it was encrypted. I found a great CI_Session extension that extends the existing Session class and it enables you to store serialized data in the db with the native CI session function calls. Here is the link: http://codeigniter.com/forums/viewthread/58731/ This .was my first experience in extending a CI library and it was effortless.