What is the best way to deal with sessions when the user may stay logged in, but a session key needs to be updated, because of another update?

Question

I'm working a site where users could technically stay logged in forever, as long as they never close their browser (and therefore never get a new session key). Here's what I could see happening: a user leaves a browser open on computer A. The then use computer B, login and change their name which is stored in the session. They logout of B, but A is still logged in and still has their old name stored in the session. Therefore, their name won't be updated till the next time they logout manually or they close their browser and open it again and are logged in through the remember me function.

Name is a simple example, but in my case the subscription level of their account is stored in the session and can be changed.

How do you deal with this?

A few ideas that I have are:

1. After a period of 10 minutes or more, the session data get's reloaded. It might be exactly 10 minutes if the user is highly active as the function will get triggered right at the 10 minute point or it could be after 2 hours if the user leaves and comes back and then triggers the functionality.

2. Store as little information as possible in the session and load the rest from the DB on every page call. (I really don't like this idea.)

3. Use database sessions and use the same session on all the computers. I like this, but I could see it getting confusing when something like search criteria are stored in the session--the same criteria would show up on both browsers/comptuers.

4. For information, even such as the user's name or username/email address, store it in the session, but for other information that would heavily affect their abilities on the site, don't store it in the session and load when needed (attempt to only do it once per instance).

Are there other better methods?

-- Another option: 5. Use database session and when an update is made load the user's other sessions (just unserialize), change the relevant information and save them back to the database.

Answer 1

Normally you should do 2), but you don't like it. maybe you can use sessions stored in db. when a user change his name, put into all sessions from that user the information "refresh userdata". on the next request the userdata is reloaded again into the session and is cached there. this can be done be reusing your loaduserdata function which called at login.

php session_set_save_handler - also read comments

php session_decode - to read the username from the session to store it additionally to the sessiondata. usefull for easily to find the users sessions for updating.

[edit] dont forget: when you are updating all the sessions while the page is generated (between session_start and session_write_close) you changes maybe lost.

Answer 2

I would go either with number 1 or number 4. If you store the time of the last update of the information, you could even ask on every request whether the date has been updated.

Answer 3

Don't store information likely to change in the session, if you're looking at scenarios like the one you outline. Just get over your dislike of loading user data with every page - it's by far the best idea.

I'm guessing you don't want to load the data from the database because you're concerned about performance issues somehow. Before you try out any of the other solutions, you might want to test how long it takes to actually load a users data from the database, then check that against your number of users - chances are you won't see any performance problems due to loading user profiles on every page.

Regards

Answer 4

I'd go with option 6: only store userid and session specific stuff (search criteria) in his session and put the rest into APC/xcache (memcached if you're using multiple servers).

this way you'll only have to go to the database the first time (and after the cache expires) and you can still share any data between users sessions.