SitePoint Sponsor

User Tag List

Page 3 of 3 FirstFirst 123
Results 51 to 66 of 66
  1. #51
    Tranceoholic lilleman's Avatar
    Join Date
    Feb 2004
    Location
    Írebro, Sweden
    Posts
    2,716
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    BluDragon: That might be a good solution... Perhaps you could show us the structure of the privilege table? I think I can guess how the other tables are constructed, but not the one holding all the privilege levels.
    ERIK RIKLUND :: Yes, I've been gone quite a while.

  2. #52
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Umm...

    You have a table for users.
    You have a table for permissions, ie

    1. Create
    2. Modify
    3. Remove
    4. Search
    0. All Access (so you don't need to maintain 1 ~ for a user, where that user requires all permissions, so it just means instead of taking x number of rows in your database table, it just uses the one)

    Then you have groups table.
    And you need some kind of table to map the request, I call it the plugins table for example.

    ...

    So, a group can have one or more users.
    A group can have one or more plugins.
    A user can have one or more permissions, to each assigned plugin with each group a user belongs to.

    That has worked for me upto now without too many limitations, but like everyone else, I'm always on the look out for something more
    Last edited by Dr Livingston; Sep 17, 2005 at 14:26. Reason: missed something out

  3. #53
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    So, a group can have one or more users.
    A group can have one or more plugins.
    A user can have one or more permissions.
    Why not have

    [users] n - 1 [group]
    [group] 1 - n [permission]

    ? This would seem like the logical thing to do. Was there some particular reason for you to do it the other way around?

  4. #54
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes I did think of that originally but there wasn't enough flexibility. For example, in your example, if you apply the permissions to the group (in practice, this is as a whole in other words), and not to the users, then for whatever plugins are assigned to a given group, all users of that group have those permissions, to do what ever they want with the plugins.

    My reference to a plugin is more akin to an Action ala MVC you see. With the approach I use, each user is independent of the plugins, or Actions, as they alone have their own permissions, not the group.

    More complexity I know, but I think this is more flexible as well, but if someone can suggest a cleaner solution, I'm all ears

  5. #55
    Tranceoholic lilleman's Avatar
    Join Date
    Feb 2004
    Location
    Írebro, Sweden
    Posts
    2,716
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Dr Livingston: Thanks for the suggestion, it seems like a good solution. However, I don't fully understand how it's constructed. The first thing that confuses me is the permissions table. Perhaps you can post the table structure, and, if possible, a small amount of example data from that table? The second thing is the "plugins" you're talking about - what is a plugin? And what do you mean when you say "you need some kind of table to map the request"? It's a lot of questions, I know, but if you have time to answer them, I'd really appreciate it.

    Thanks in advance.
    ERIK RIKLUND :: Yes, I've been gone quite a while.

  6. #56
    SitePoint Member danfluidmind's Avatar
    Join Date
    Feb 2004
    Location
    Louisville, KY
    Posts
    19
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    First of all, I completely understand your desire to write it yourself instead of trying to plug someone else's code into your app. What I HIGHLY recommend is the following:

    1) Go to http://phpgacl.sourceforge.net/ (Generic Access Control Lists)
    2) Download the manual (sadly, it's a PDF)
    3) Read the introduction, which will give you a VERY good understanding of Access Control Lists.
    4) Download GACL and just play with it to see how it works, go through the tutorial in the manual, take a look at the database tables that it uses.
    5) From the understanding you gain from steps 3 and 4, write your own ACL routines for your app.

    Good luck.
    --Dan

  7. #57
    Tranceoholic lilleman's Avatar
    Join Date
    Feb 2004
    Location
    Írebro, Sweden
    Posts
    2,716
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for the tip, Dan. I'll do that.
    ERIK RIKLUND :: Yes, I've been gone quite a while.

  8. #58
    SitePoint Evangelist Will Kelly's Avatar
    Join Date
    May 2005
    Location
    London
    Posts
    475
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I wish all manuals used Star Wars in their examples. Everything would be soooo much easier to understand...

  9. #59
    SitePoint Member danfluidmind's Avatar
    Join Date
    Feb 2004
    Location
    Louisville, KY
    Posts
    19
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Will Kelly
    I wish all manuals used Star Wars in their examples.
    Wouldn't that be nice?

    phpGACL is a really nice app. I considered just using it as-is for my apps, but there's one thing I don't like about it. It was apparently originally designed to handle two types of things: Access Control Objects (the things you want to control access TO) and Access Request Objects (the things you want to control the access OF--i.e., users). The problem with that is that there's no control of ACTIONS on those objects. So they added something they call "Extended Control Objects". The problem is that you make the Extended Control Objects take the place of the Access Control Objects, then you use the Access Control Objects as "Access Control Actions" (so to speak). Why they didn't simply add "Access Control Actions" I don't know. But they way they have it set up seems confusing to me.

    Aside from that, they use damn acronyms for everything ARO, ACO, XCO...BLAH!!! I'd rather just call the things what they are: Requestors, Control Objects, Actions. Simple.

    --Dan

  10. #60
    SitePoint Evangelist
    Join Date
    Feb 2005
    Posts
    581
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lilleman
    BluDragon: That might be a good solution... Perhaps you could show us the structure of the privilege table? I think I can guess how the other tables are constructed, but not the one holding all the privilege levels.
    One table stores the user names with the fields userId, userName, and password. Another stores the user data with fields like userId, name, info, and privLevel. The third table stores the privilege levels with fields such as levelId, levelName, and permissions. The username table is joined to the userdata table on the userId fields and the privilege data table is joined to the userdata table on the privLevel field being equal to levelId.

    If I had my computer in front of me I could give you some code and SQL dumps but I unfortunately I don't as I am at the library.
    I will not flame the newbies,
    I will not flame the newbies,
    I will flame the newbies...
    Table free is the way to be!

  11. #61
    Tranceoholic lilleman's Avatar
    Join Date
    Feb 2004
    Location
    Írebro, Sweden
    Posts
    2,716
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks, that explanation made it more clear. However, if you have time, a dump of the privilege table would be very welcome.
    ERIK RIKLUND :: Yes, I've been gone quite a while.

  12. #62
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    However, I don't fully understand how it's constructed. The first thing that confuses me is the permissions table. Perhaps you can post the table structure, and, if possible, a small amount of example data from that table?
    Code:
    -- phpMyAdmin SQL Dump
    -- version 2.6.0-pl3
    -- http://www.phpmyadmin.net
    -- 
    -- Host: localhost
    -- Generation Time: Sep 17, 2005 at 10:30 PM
    -- Server version: 4.1.8
    -- PHP Version: 5.0.3
    -- 
    -- Database: `tmpdb`
    -- 
    
    -- --------------------------------------------------------
    
    -- 
    -- Table structure for table `permissions`
    -- 
    
    CREATE TABLE `permissions` (
      `task_id` tinyint(3) NOT NULL default '0',
      `user_id` tinyint(3) NOT NULL default '0',
      `access` tinyint(3) NOT NULL default '0',
      PRIMARY KEY  (`task_id`,`user_id`,`access`)
    ) ENGINE=InnoDB DEFAULT CHARSET=latin1;
    
    -- 
    -- Dumping data for table `permissions`
    -- 
    
    INSERT INTO `permissions` VALUES (1, 1, 1);
    INSERT INTO `permissions` VALUES (1, 1, 2);
    INSERT INTO `permissions` VALUES (1, 1, 3);
    INSERT INTO `permissions` VALUES (1, 1, 4);
    INSERT INTO `permissions` VALUES (1, 1, 5);
    INSERT INTO `permissions` VALUES (2, 1, 1);
    INSERT INTO `permissions` VALUES (2, 1, 2);
    It's a lot of questions, I know, but if you have time to answer them, I'd really appreciate it.
    A plugin in my reference is just your basic Command or Action, where that given Command or Action has a name, ie Accounts (user accounts for example), which is passed to a simple Permissions class, along with a request parameter, ie

    Code:
    www.sampledomain.com?act=show
    So, with these two variables, and the Users ID I pull out the permissions assocc. with Accounts for that user, ie

    PHP Code:
    class Permissions {
            
            static public function 
    ask$task ) { 
                
    $db DbFactory::getConnection();
                
    $sql "-- requires 
                        -- + *.permissions
                        -- + *.tasks
                        -- fetch permissions assocc with user and task
                        
                    select distinct permissions.access as access 
                      from tasks, permissions 
                    where permissions.user_id = ? 
                    and tasks.task_id = permissions.task_id 
                    and tasks.task_name = '?'"
    ;
                    
                
    $stmt $db -> createStatement$sql );
                
    $stmt -> setInteger1Session::get'id' ) );
                
    $stmt -> setParameter2$task );
                
    $rslt $stmt -> execute();
                
    $access = array(
                    
    => 'all',
                    
    => 'create',
                    
    => 'modify',
                    
    => 'remove',
                    
    => 'search',
                    
    => 'show' );
                
    $array = array();
                while( 
    $rslt -> fetch() ) {
                    
    $array[] = $access[$rslt -> getField'access' )];
                }
                return 
    $array;
            }
            
            static public function 
    can$action$task ) { 
                static 
    $permissions;
                if( !isset( 
    $permissions ) ) {
                    
    $permissions Permissions::ask$task ); 
                }
                if( 
    in_array$action$permissions ) || in_array'all'$permissions ) ) {
                    return 
    true;
                }
                return 
    false;
            }
        } 
    And use it like so,

    PHP Code:
    if( Permissions::can$action /* from request */'accounts' ) ) {
    // perform action
    }
    // do something else 
    I might add though, that I do this authentication prior to the action being executed via Intercepting Filters (to me, it's cleaner and I can swap in/out these filters easily)

  13. #63
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If you use this SQL you can pull out all the plugins assocc. with the user in question I believe?

    Code:
    $sql = "-- requires
                        -- + *.permissions
                        -- + *.tasks
                        -- fetch permissions assocc with user and task
                        
                    select distinct permissions.access as access
                      from tasks, permissions
                    where permissions.user_id = ?
                    and tasks.task_id = permissions.task_id";
    So that if you wanted to, you could cache the whole results to a file, which you fetch instead of going to the database on every request. But since your only interested in one plugin in current use, I don't see the point of pulling out more data than what is needed.

  14. #64
    Tranceoholic lilleman's Avatar
    Join Date
    Feb 2004
    Location
    Írebro, Sweden
    Posts
    2,716
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks, now I understand how your solution works.
    ERIK RIKLUND :: Yes, I've been gone quite a while.

  15. #65
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Another direction that you go is to use the Nested Set approach? Reading about this the other day there to refresh my memory, and regarding this I read (Celko) that for each sub set of nodes, you can calculate the level automatically.

    So, knowing that, you can specifically give one user a position within the hierarchy, knowing that they'll have a set level value. So one user who is higher up the hierarchy, over another user who is lower down, could have their priveleges, and their own priveleges, as dictated to, by their level value.

    You assign a number of group(s) to each level that is possible, based on the hierarchy that you have. So the root user would have their own group(s), and all those that are below (further down the hierarchy) them if that makes sense?

    Code:
    Administrator (1)
    +--- Publisher (2) 
    +--- --- Editor (3) 
    +--- --- Authorer (3)
    So, you have these groups, below

    Code:
    * GroupA
    * GroupB
    * GroupC
    * GroupD
    * GroupE
    So, if Authorer belongs to Group E, and an Editor belongs to Group D, Publisher belongs to Groups B and C, then Publisher would also belong to Groups D and E, as Publisher is higher up the hierarchy.

    Much so, an Administrator who belongs to Groups A and B, they too would also belong to Groups C, D and E as well. If you can see the picture here, then it makes sense that those users further up the hierarchy have more groups, or priveleges that would be assigned to each group in question.

    The lower down the hierarchy, the less priveleges you have. Based on this thought, it makes sense, as from a business model, it's the same hierarchy structure of organised management, isn't it?

    This is what is going through my mind at the moment, and hope to spend some more time to look into it, since on the surface, it appears to be a cleaner method to use, what I'm using at the moment

    Is this any help to you?

  16. #66
    Tranceoholic lilleman's Avatar
    Join Date
    Feb 2004
    Location
    Írebro, Sweden
    Posts
    2,716
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    Is this any help to you?
    I think so. Perhaps you (and me, and others) can continue to discuss this solution? That way, we can all learn something, and it'll probably be of use for other people in the future.
    ERIK RIKLUND :: Yes, I've been gone quite a while.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •