Codeigniter Storing sessions in a database

[fortnox007]

Hi all,

 

I read something about storing sessions in a database adn that certainly sounds like a great extra on a shared host. only thing i wasn't able to figure out how to clear the database of expired sessions. So i asked the mighty google and codeigniter popped up and it seems to be able to do all this.

 

The question is, does anyone have experience using this and could you reccommend it, or maybe something else if it ends up being sucky.

 

If someone btw knows the mechanic behind the clearing of the database sessions i would love to hear how that works 9both in general and if you have time in specific hehe  )

[ignace]

session_set_save_handler

[fortnox007]

Yeah i found that, but that doesn't automatically clear the sessions from the database right? I was thinking it could be done with a cronjob and a timestamp or something. but not sure if that is the best way.

[PFMaBiSmAd]

I read something about storing sessions in a database adn that certainly sounds like a great extra on a shared host.

 

Not really. On a shared web host, all the databases on any database server can been 'seen' by all the accounts that use that database server (and in fact all the database servers present are usually accessible by all the accounts) and since at least mysql does not have any bad username/password detection and lockout, it is fairly easy to break into someone else's database on a shared web server. Only the strength of the username/password keeps your data safe. Of course, if your site requires good security, you would not be hosting it on a shared server to begin with.

 

The safest and simplest way of protecting session data files on a shared web server is to set the session.save_path to be to a private folder within your account's folder tree.

 

The codeigniter code is used in place of the built in session handling (you don't use $_SESSION variables at all with it.) So, it would require rewriting all your code that sets or references $_SESSION variables.

 

Back to your question. If you did replace the built-in file session save handler with a database driven handler (there are existing php scripts posted all over the Internet), so that as far as your application code is concerned, nothing about the use of session variables is changed, the garbage collection operates exactly the same way as when using the built-in file session save handler. There is a garbage collector function that gets randomly called, based on session.gc_probability and session.gc_divisor settings, when the session_start() code gets executed. In the case of the file based session save handler, files with a last accessed time older than the session.gc_maxlifetime setting will be deleted. In the case of a database based session save handler, records with a last accessed time older than the session.gc_maxlifetime setting will be deleted.

 

You should not rely on the operation of the session garbage collection to do anything but to clean out OLD session data files/records, mainly because it runs randomly (you should leave it running randomly) and OLD session data files can exist for an indeterminate time after the visitor is no longer active on your site.

 

The php source code can be examined to learn exactly how the above is accomplished (I have actually looked at the session garbage collection code - I was curious if the session.gc_probability and session.gc_divisor was truly random or was some count.)

[PFMaBiSmAd]

Yeah i found that, but that doesn't automatically clear the sessions from the database right?

 

Yes it does clear out old session records.

[fortnox007]

Oh wow thanks a lot PFMaBiSmAd for you detailed response. I really appreciate it. And iit helped to give me more of an inside. Just a small question. You say I 'should leave it running randomly' followed by 'OLD session data files can exist for an indeterminate time after the visitor is no longer active on your site.' I suppose they will eventually be removed right, but randomly? i know joomla uses a similar approach but there i can manually end a session, i suppose i can do that here too and that there are no drawback's on that except for the possibility of kicking someone out while he is still active?

 

And yeah I am aware of the crappiness of shared hosts, but at the moment i don't have the luxury of paying atleast 50 euro's a month (aside from SLA costs, and my inexperience of setting up a server making it probbaly les secure than a shared host hehe ) So i hope to create something that makes atleast 50 euro's a month and than switch to a dedicated thing

[PFMaBiSmAd]

I suppose they will eventually be removed right, but randomly?

 

^^^ Yes.

 

i know joomla uses a similar approach but there i can manually end a session, i suppose i can do that here too and that there are no drawback's on that except for the possibility of kicking someone out while he is still active?

 

A session is just a container that allows variables to persist between page requests. There should be no need to manipulate the actual session or the data in it and the people who try end up with a lot of extra code and special case conditions that can be bypassed. What exactly are you trying to accomplish?

[fortnox007]

Oh well i just thought it would be fun to see in some sort of back-end how many people are logged in with names and stuff. Always fun to see visual success. And i must honestly say until yesterday i didn't knew of this technique until i read a blog of chris Shifflet. I just like to learn a lot about security, because that is really my main concern. But that also makes me hesitate the whole time to launch stuff hehe And i rather do things myself instead of just copy pasting someone's script without knowing what is happening. But there is so much to read and learn kinda hard for a non full-time coder

But i really appreciate the help i get here and the nice tutorials

[PFMaBiSmAd]

Displaying user information - what page they are on/last requested, how many are log in, logged in user names... involves storing that information using an easy to access method. Storing it in a session using $_SESSION variables is not the best way, even if using a database by changing the session save handler. The session data is serialized before it is passed to the session save handler, which means accessing any specific part of it where it is stored, such as getting all the user id's/user names would require that you retrieve each relevant record and unserialize the data.

 

Normally, either the existing user table or a separate table is used to store the needed information in a format where it can be directly accessed and this is done separately from any use of session variables in your application (except for using a session variable that identifies the visitor.)

 

Back to the Codeigniter link you posted (the subject of this thread), yes they are storing user/session data in a database and generating a corresponding id that gets stored in the client using a cookie. You can use this side-by-side with your normal $_SESSION variables. It could be added to any application and used to keep track of the user information.

[fortnox007]

Okay cool, i didn't knew it had to be serialized and it's good to hear there are better ways. hehe i think ill try out that code-igniter and also try to make this myself including the visitors table. in the end i think that's the best way to fully understand it. Thanks m8! have a nice new year!

[ignace]

I should note that CodeIgniter does not use $_SESSION but $_COOKIE instead to store it's session data. You are warned!

[fortnox007]

Thanks Ignace, i rather not use cookies since they can be disabled and easily be stolen