I've read conflicting information on this topic, so I'm hoping with the scenario I put forth, one plan will be more ideal than another.
In my case there are "users" who have access to "groups" that are comprised of "sections". Each section can have a different permission level based on how the user is configured. So I may be an "admin" for a section, while my coworker is "basic".
After logging in, a user would choose the group they want to manage/view. My original plan was to lookup the user/group/section/permisison info and store in an array in session like...
$_SESSION[group_id][sectioin_id]['permis开发者_StackOverflow社区sion'] = 7; // 1+2+4 (R+W+X)
Then when they go to a page, I could look up what group they're in, see what section page their on, and display the appropriate info based on their permissions.
Alternatively, I could build a DB lookup script to check this info, but it will have to lookup across multiple joined tables and parse the results for EACH PAGE. This seems inefficient to me, but from what I'm reading about how sessions are written for each page, it may not be so.
Thanks for any ideas/suggestions.
// ---- more info on possible session size
Right now a group has a max of 5 sections, with up to three pieces of data. The max size of the session currently would be something like:
$_SESSION[1][1]['permission'] = 7;
$_SESSION[1][1]['type'] = 'paid';
$_SESSION[1][1]['expires'] = '2011-08-01';
$_SESSION[1][2]['permission'] = 7;
$_SESSION[1][2]['type'] = 'free';
$_SESSION[1][3]['permission'] = 7;
$_SESSION[1][3]['type'] = 'paid';
$_SESSION[1][3]['expires'] = '2011-08-01';
$_SESSION[1][4]['permission'] = 7;
$_SESSION[1][4]['type'] = 'paid';
$_SESSION[1][4]['expires'] = '2011-08-01';
$_SESSION[1][5]['permission'] = 7;
$_SESSION[1][5]['type'] = 'free';
This would be the case where section's 1,3,4 are at a paid level and 2,5 are at the free version. Is that too much session stuff to track per login?
I'd call that a pretty ugly hack. What you're trying to do is to build up a big object and hold onto it across multiple executions of the php interpreter. Sneaking the object into session data is clever but the "wrong" way to do it.
Keep in mind that with your method, for every new user session you're storing the complete set of permissions tables, duplicating the same data over and over.
IMO you should take the expensive lookup hit at login time (there's probably no other heavy lifting to do then anyway) and then keep the user's permission mask in his/her session, like $_SESSION["permission"] = 7
If you really want to save a permissions provider across multiple interactions, look into object serialization; you can store objects in your database for real without abusing $_SESSION.
Either way is going to function. Things to note:
- How sensitive is access to the system? If you go the session approach and a user gets disabled or a permission removed, they're going to still have access until their next login.
- Session data should be limited in size. If you've got a million groups/sections/permissions, your session data will be quite large and slow to process.
精彩评论