Storing user session variables in file vs in database
Asked Answered
O

5

13

I've got a php application and I'm saving the session variables for the user using $_SESSION itself. Is there any particular advantage of storing it in a database?

I'm looking for a reliable / well-researched article which talks more about this. I havent been able to locate anything yet.

Ostrich answered 25/5, 2011 at 9:26 Comment(2)
Is there a problem with your current implementation? If not, this doesn't strike me as an SO type question. By my understanding we're here to solve problems, not discuss hypothetical benefits. If the former is applicable, it'd be helpful to know what actual problems you're encountering.Olli
@Jeff Parker agree this would be a better fit for programmers.stackexchange.comTalmudist
T
2

At some point in time you're going to have to store something in a session. Whether it's all the session variables or just the ID of a row in a sessions table. That being the case it would be fairly easy to alter the ID stored in a badly encrypted session and hijack a different session.

Consider this:

Full Session Option. This has the User ID, Username and an encrypted and hashed password stored so that every time a page is called it verifies my login. To hijack someone else's session I'd have to know their User ID, Username and Password Hash and be able to overcome the sessions inherent encryption.

Session + DB Option. This just has a Session ID stored that references a row in a database. All I have to do to change the session I want is to break the encryption on the session and say add one to the Session ID. I'd then be authenticated as the user that logged in after me.

You could store login details in a session and then any none login related data in a session table if you have a lot of extra information but then again you might as well just remove the need for an extra table and extract the data from whatever relevant tables you need.

Traynor answered 25/5, 2011 at 9:34 Comment(0)
A
6

The advantage you have of storing it in a database is that the data exists as long as you want it to exist.

Your browser will destroy the session according to how it is setup, which makes it a bit unreliable. I can't however find an article on this yet but this is what I use as a convention for a situation like this.

Any data that needs to be stored long term, like user details and activity I store in a database. Any data that is only relevant to the current workspace, like logging into a site and posting a few comments etc. can be stored in the session. For instance I store user authentication details in a session to constantly check whether the user is logged in or not and whether to redirect him/her to the correct page.

This works wonders when checking access rights throughout your application.

For me its much safer to store user details in a database because it cannot be publically accessed like the $_SESSION.

Please disagree with me if you want to though.

Alkali answered 25/5, 2011 at 9:34 Comment(1)
And how exactly could $_SESSION be public accessed?Galegalea
S
6

I would say storing in database is better.Because

  1. When you are hosting your site with a shared host PHP uses the same path for storing sessions for all the users,somewhere that is not in your folders.

  2. You can track the users and their status easily.

  3. For application that are running on multiple servers, you can store all the session data in one database.

This article may help.

Staffan answered 17/7, 2011 at 12:58 Comment(1)
storing authentication tokens in the database might affect the app performance when you have to validate for each request.Lacedaemon
T
3

Well this is a question for the ages. Personally from what I have learned in my time. Unless your site starts booming on a massively large scale where you need to start using multiple servers for various aspects of the system such as load balancing where you have many mirror systems running. Or need to improve performance a little for an over populated system the benefits of using DB related sessions or File based sessions really isn't any different.. Grant it I could be wrong this is merely my own personal perception off my own experiences. Just like you Ive never really found any articles, posts, other that really put either to the test side by side hell I don't even think I have found anything that really puts either to the test stand alone for that matter. Personally I just go with what ever the need is (or desire of my client) usually I just stick to native sessions file based.

I hear they can be spoofed, but have seen no proof to that notion to date. So other than that potential I stick with file based. Unless I am using a system like code igniter then sessions seem to handle better DB driven with it rather than not.

Tita answered 25/5, 2011 at 9:41 Comment(0)
T
2

At some point in time you're going to have to store something in a session. Whether it's all the session variables or just the ID of a row in a sessions table. That being the case it would be fairly easy to alter the ID stored in a badly encrypted session and hijack a different session.

Consider this:

Full Session Option. This has the User ID, Username and an encrypted and hashed password stored so that every time a page is called it verifies my login. To hijack someone else's session I'd have to know their User ID, Username and Password Hash and be able to overcome the sessions inherent encryption.

Session + DB Option. This just has a Session ID stored that references a row in a database. All I have to do to change the session I want is to break the encryption on the session and say add one to the Session ID. I'd then be authenticated as the user that logged in after me.

You could store login details in a session and then any none login related data in a session table if you have a lot of extra information but then again you might as well just remove the need for an extra table and extract the data from whatever relevant tables you need.

Traynor answered 25/5, 2011 at 9:34 Comment(0)
P
0

From my short experience, you should store in $_SESSION only data that you will NOT need to be refreshed in all sessions opened by a unique user in different devices. (mobile/desktop/etc.)

In other words, data that you are sure will never change like a userID.

For example, I had stored the user profile picture path into $_SESSION and it led to a strange User Experience. When changing the profile picture in a desktop, it did not refresh the profile picture for the user on his mobile. Other users saw the new picture though. Indeed, the path was refreshed into the DB but not in the $_SESSION. Login-out and Login-in would not change anything.

Remember that the default behavior is that $_SESSION passed with cookie will be different for each browser even if this is the same user logged in. You will have to do a session_destroy() to avoid being stuck with old data.

Very temporary data may be stored in $_SESSION as well I guess.

NB: the basic need of global session, out of these arguments, is to have variables available globally

Postmark answered 22/1, 2018 at 18:31 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.