Storing logged in user details

Question

When creating a web application, and lets say you have a User object denoting a single user, what do you think is the best way to store that the user has logged in?

Two ways I've thought about have been:

• Stored the user database id in a session variable
• Stored the entire user object in a session variable

Any better suggestions, any issues with using the above ways? Perhaps security issues or memory issues, etc, etc.

Answer 1

Just remember that if you store all the user's attributes (this extends to permissions) in the session, then any changes to the user won't take effect until they login again.

Personally, I store the name and id for quick reference, and fetch the rest when I need to.

Answer 2

I think that it depends on what platform you are using. If you are using ASP.net, then I would definitely take a look at the FormsAuthentication class and all of the built-in (and extendable) functionality there that you can use for storing your logged-in user settings.

Answer 3

Storing the ID is the best practice in most cases. One important reason for this is scalability. If you store the user object (or any entities from the database, instead of just their IDs), you are going to run into problems expanding the number of servers serving your site. For more information, google for "shared nothing architecture".

Answer 4

I store the user in the session, usually. The can't-change-until login problem can be solved by replacing the object in the session with a new copy after you've made changes.

Answer 5

Our user object is fairly lightweight so we opted to store it in a session variable. Not sure if that's most efficient but so far it's working very nicely.

Answer 6

I recommend storing the id rather than the object. The downside is that you have to hit the database every time you want to get that user's information. However, unless every millisecond counts in your page, the performance shouldn't be an issue. Here are two advantages:

1. If the user's information changes somehow, then you won't be storing out-of-date information in your session. For example, if a user is granted extra privileges by an admin, then those will be immediately available without the user needing to log out and then log back in.

2. If your session information is stored on the hard drive, then you can only store serializable data. So if your User object ever contains anything like a database connection, open socket, file descriptor, etc then this will not be stored properly and may not be cleaned up properly either.

In most cases these concerns won't be an issue and either approach would be fine.

Answer 7

For security's sake, I would generate (either a GUID or cryptographically safe RNG) a session ID and have a table that just maps session IDs to user IDs. Then, you just store the session ID in their cookies, and have it act as a proxy for the user id.

|Session |UserID |
|--------+-------|
|a1d4e...+ 12345 |
|--------+-------|
|c64b2...+ 23456 |
|--------+-------|

With this, no one can impersonate another user by guessing their ID. It also lets you limit users' sessions so they have to log in every so often (two weeks is the usual). And if you want to store other data about their session, you can just add it to this table.

Answer 8

I would store a hashed value of the user id and the session id and then match that up in a sessions table in the database. That way it will be harder to spoof the session data. Could do i check on the IP too as an extra check.

Not sure i would want to rely on a userid being stored in a session variable and trust that it was that user as it could be altered fairly easily and gain access as another member