Considering a new technique for user profile

[BlindPete]

Essentially I am trying to consider which technique is best for:
end user performance, server and database performance and ease of maintenance

A web application with various user levels and various permissions for each user group and sometimes even specific permissions for certain users. So for discussion purposes lets say I have six user types: GOD, ADMIN, MAINT, EDITOR, WRITER, and VIEWER.

I have tables GROUP, PERMISSION, USER and SESSION that all interelate to establish who the user is, where they are and what they are allowed to do.

When a client first logs in a session cookie is created and relates back to a record in the SESSION table from which all the permissions are retrieved. For discussion purposes lets say that it is a fairly complex application and the complete user's permission set boils down to 50 parameters.

Ok so here is my quandry as to which techinque is best.

A) I could store all 50 parameters in the session cookie. I dont like this for lots of reasons but its an option.

B) Store the session ID only in the cookie and then with each page load execute a query to valid the user and verify access etc.

C) Store the session ID only in the cookie and but when the session is created cache the entire user profile to file (same name as sessionID) on the server (cleanup by CRON when expired). In this way each page load checks the cookie, gets the session ID, includes that users profile (if it exists) and validates the user and verifyies access etc.

I have never actually done Option C but I like the idea of not running a query(ies) with each and ever page load to validate the user. And I assume that the include() would be faster in any event. There are additionally security concerns that would have to be considerred, but all of that would happen at the initial login only. So is option C worth a go at trying out or should I stick with my tried and true option B?

I subscribe to the print edition of this magazine

http://www.phparch.com/

and got the idea from the November issue's Tips-n-Tricks section... which they dont publish online else I'd post the link. :-(

-Pete
Do you get a little guilty pleasure when a celebrity has a bad day?
Well then The Dead Pool is for you!

http://www.nowthatsodd.com/deadpool/

 

[sleipnir214]

You seem to have some confusion over how sessions work. If you are using PHP's session-handling mechanism, all that is ever stored in the session cookie is the session store index. The actual content of the session variables is only stored on the server.

Also, PHP has a garbage-collection mechanism already built into its session-handling mechanism. By tweaking the values for the PHP runtime configuration directives session.gc_maxlifetime and session.gc_probability. maxlifetime sets how long a session variable will last before it is eligible for deletion. probability sets the percent chance that garbage-collection will fire off every time a script issues session_start().

In terms of what to store in the session, I'd say store only the non-dynamic information. When a user successfully logs in, set a specific session variable (say, $_SESSION['logged_in_user']) to a unique value appropriate to your schema (I usually have and auto_increment ID column in my user column, and set that variable to that value). That value is not going to change until the session expires or the user logs out. (When the user logs out, unset the variable.)

However, your permissions system must be dynamic. If an admin-class user gives a viewer-class user permission to some piece of content, the viewer-class user should not have to log in and log back out to see the newly-available content. Thus, permissions are checked each time, using the ID from the session variable.

Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!!