methodologies for managing session variables

Question

I've been reading up on (mysql) triggers the last few days... specifically what I'm trying to do is figure out a good methodology for updating a user's information.

---

The case use for this is related to a user management system: Take for instance a admin user updating a regular user to a manager, this user type change would then enable|disable software features on the interface.

Problem: You won't know about this user type change unless you query the database and reset say for example the $_SESSION['user']['type'] variable, and or the user logs-in|out of the system.

---

Question: Is there any good methodologies to solve this headache?

Answer 1

I don't think mysql triggers would be ideal for this. Why? Because you will most probably end up with part of logic in php and part in mysql. It's a good thing to stay with one technology because it will be easier to maintain/debug code for you and your colleagues later.

So in your case, if you want the change of user role would take immediate action, you would have to either load user role on each script run or log out user using some flag in database that would signal that his session is not valid anymore (or you could implement your own session_set_save_handler that would save session somewhere in file where you could delete it to log out user).

It depends on your needs which solution would better fits your case.

• If your roles logic is complicated and it consists of multiple roles assigned to one user as well as extra permissions assignments/excludes per user it may be better to do this check once on user log in and then just remember the result using session.
• If checking for permissions on each script run isn't an issue, you can do it. But be aware, for security reasons, it may be a good practice to force user to log in again.
• If the user log out could cause lose of work, you should let user log out itself and apply new permissions after next log in (you can show user a message that new permissions are awaiting log in to take effect).

So it really depends on your needs to choose if it's better to log out user, give him new permissions right away or wait until next log in.

Answer 2

Question: Is there any good methodologies to solve this headache?

Find good reasons not to do it!

While this might sound like a joke, i am completely serious. You have to consider:

• What is the value of that feature?
• Is it worth the headache cost?
• What are the risks of that feature (incomplete work / system consistency)?
• Do you have to change the system core?
• Would you have to revalidate the system?
• Are there other really great features (system improvements) waiting to be implemented?

Someone who doesn't feel comfortable answering these questions doesn't really need that feature.

Find simple alternatives:

• Call the user and ask to log out.
• Notify the user per email.
• Provide a button for email notification.
• Send email notification automatically after changing permissions.

This is no laziness. Just focus on real value.