CI Sessions saved to database question

[eluser]mikegioia[/eluser]
Hi Guys -

I've just set up my database to accept the session info from CI and it works and everything. My question, though, is whether or not thats all I need to do.

I see the in the database that the info is being stored. Does CI take care of the validation or do I need to run a check in my app code? Also, will have any impact on page load or performance (I doubt it will) ?

Thanks in advance,
Mike

[eluser]adamp1[/eluser]
Yes that's all you need to do. Validation of what? the Ip and things? I would have thought the session class would handle all of this.

It will have an effect but it will be so small you won't even see a difference, where talking hundreds of a second difference probably.

[eluser]mikegioia[/eluser]
Thanks adamp1. For validation I meant like say the user changes one of the cookie values. Does CI check whether or not something like that happened?

[eluser]adamp1[/eluser]
No it dosn't, but there are ways to protect against this. The best way is to look at the 3rd party session libraries. They instead of storing session values in a cookie on the clients PC, store them in the DB table. This means the client cannot change the values, they only have access to to a session_id which links them to the values in the database. Changing this will just loose them there session.

I havn't tried any of them as of yet, but I would look into them if your worried about clients changing data.

[eluser]bikuta[/eluser]
If I want to store extra information than the generic ci_sessions table, e.g., userid.
Will CI write the data into the table for me when I assign userid a value? or do I have to do that myself?

[eluser]mikegioia[/eluser]
Hi bikuta -

It depends on if you're using the CI session library or OB Session, DB session or one of the other third party session libraries.

I had the CI session class running and it didn't store any data in the database. It just used the database to verify the session id. So, CodeIgniter doesn't actually write the session data you set (like userid) to the database.

If you're using OBSession (which I really recommend) then all data (like userid, firs_name, etc) will be saved to the database and you still don't need to do anything differently. OBsession has good documentation on setting up the database table and configuring the class.

Either way, CodeIgniter handles that aspect of sessions. I would just recommend using a third party session library since storing the data in the database seems the safest bet.

Mike

[eluser]MadZad[/eluser]
bikuta - you'll find quite a few forum posts on this topic, so there's much wisdom to be gained with a little searching.

For what we do, I'd largely ditto mikegioia's post. We selected OB Session because we really wanted all session info (from simple like "userid" to larger like search results). Additionally since OB Session allows us to specify a database, that became indispensable - we have multiple apps, each with their own DB, but user and session info is in a shared DB. When upgrading to CI 1.6.1, we would have probably ditched OB Session for CI 1.6's new-and-improved session class if it had that capability (which honestly is unnecessary for most folk). Fortunately, OB Session still works fine with CI 1.6.1, but be aware that it's no longer supported for CI by it's developer (he's at Kohana now).

But, life really is easy when saving various stuff into the DB-based session:

Code:

//store
$this->session->set_userdata("userid", $my_userid);
$this->session->set_flashdata("error_message", "bad input, man");
$this->session->set_userdata("lots_of_data", $my_data_array);

//retrieve
$fetched_userid = $this->session->userdata("userid");
$err_msg = $this->session->flashdata("error_message");
$data_array = $this->session->userdata("lots_of_data");

//cleanup
$this->session->unset_userdata("userid");
$this->session->unset_userdata("lots_of_data");

and code written by others takes care of the nuts-n-bolts. Another post covering Multi dimensional arrays in Sessions

Now, there will be other situations where this might be impractical, such as trying to limit DB hits. So, DB storage of session info is not one-size-fits-all, so assess your own cost/benefits.