SitePoint Sponsor

User Tag List

Page 2 of 11 FirstFirst 123456 ... LastLast
Results 26 to 50 of 267
  1. #26
    SitePoint Evangelist
    Join Date
    Dec 2003
    Location
    Arizona
    Posts
    411
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    How closely do you want to stick to the spec?
    We don't have to stick to the spec, but I don't see anything horrible about it.

    Two questions:

    What is wrong with a user object? To me something like:

    PHP Code:
    if ($user->hasPermission('edit''article')) {


    is self-documenting. A User is a real world entity that has roles and permissions, etc... It is almost directly codifying the question that we want to ask: "Does this user have permission to do this operation on this object?"

    Secondly, what is wrong with unique identifiers?

    Thanks,

    JT

  2. #27
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by seratonin
    What is wrong with a user object?
    For a library it's scope is too large. For example if you decide to add email contact to your application users where does it go? Sounds like it should go into the same user that is the authentication system. You can't though, as that is supposed to be decoupled from the rest of the system. By simply changing the authorisation system's name to Usage/UserIdentifier/Fingerprint you have restricted it's scope. Now it is something that can be attached to the user in the application (the one with an email address maybe). It also means that there can be multiple logins for a single person. Having multiple user's for a single person on the other hand just does not make sense.

    Another problem I outlined before. You don't ask the user for permission. You ask the authoriser for permissions that you query. That extra step, of turning an entity (user) into a simple value object (permission), really adds lot's of flexibility. It is a safely copyable object for example and is a less complex item to load.

    I once saw a User class/table (actually called Subscriber) destroy a whole project. The notion is deceptively vague.

    Quote Originally Posted by seratonin
    Secondly, what is wrong with unique identifiers?
    Nothing (?). Do you mean for object IDs that we reference? In that case plenty if we are a library and we are forcing them on an application. Our tendrils are spreading faster than they should. If you can come up with a clean way of introducing them as an optional item, then there is no problem.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  3. #28
    SitePoint Evangelist
    Join Date
    Dec 2003
    Location
    Arizona
    Posts
    411
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Here is a simplification of my previous XML document. I merged together operations and objects and I removed any references to ID's.

    Code:
    <?xml version="1.0"?>
    <rbac>
      <rbac-users>
        <rbac-user name="John"/>
        <rbac-user name="Jane"/>
      </rbac-users>
      <rbac-roles>
        <rbac-role name="Employee"/>
        <rbac-role name="Manager"/>
      </rbac-roles>
      <rbac-permissions>
        <rbac-permission name="CreateDocument"/>
        <rbac-permission name="RetreiveDocument"/>
        <rbac-permission name="UpdateDocument"/>
        <rbac-permission name="DeleteDocument"/>
      </rbac-permission>
      <rbac-user-roles>
        <rbac-user-role rbac-user="John" rbac-role="Employee"/>
        <rbac-user-role rbac-user="Jane" rbac-role="Employee"/>
        <rbac-user-role rbac-user="Jane" rbac-role="Manager"/>
      </rbac-user-roles>
      <rbac-role-permissions>
        <rbac-role-permission rbac-role="Employee" rbac-permission="RetreiveDocument"/>
        <rbac-role-permission rbac-role="Manager" rbac-permission="CreateDocument"/>
      </rbac-role-permissions>
    </rbac>
    Please let me know what you think.

    Thanks,

    JT

  4. #29
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by seratonin
    Please let me know what you think.
    Looks fine to me. If you use "id" fields doesn't that guarantee uniqueness. Are you thinking of storing things this way?

    Some rapid hacking using MySql as storage...
    PHP Code:
    class Authenticator {
        ...
        function &
    getPermissions($username$password) {
            
    $this->_storage->getPermissionsFinder();
            return 
    $finder->findByLogin($username$password);
        }
    }
    class 
    MySqlPermissionsFinder(&$connection) {
        ...
        function &
    findByLogin($username$password) {
            return new 
    Permissions($this->_connection->select(
                    
    'select from permissions, roles, logins where...'));
            
        }
    }
    class 
    Permissions {
        var 
    $_operations;

        function 
    Permissions(&$iterator) {
            
    $this->_operations = array();
            if (! 
    $iterator) {
                return;
            }
            while (
    $row $iterator->next()) {
                
    $this->_operations[] = $row['operation'];
            }
        }
        function 
    can($operation) {
            return 
    in_array($operation$this->_operations);
        }

    A sideline: Does anyone know anything about LDAP? I thought it was designed for this kind of thing?

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  5. #30
    SitePoint Evangelist
    Join Date
    Dec 2003
    Location
    Arizona
    Posts
    411
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    Are you thinking of storing things this way?
    Yes, as an alternative to storage in an RDBMS even though an RDBMS seems more suitable in how you can handle relationships.

    JT

  6. #31
    SitePoint Evangelist
    Join Date
    Dec 2003
    Location
    Arizona
    Posts
    411
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Let's flesh out the rest of your implementation (if you haven't already) and identify the various design patterns used. I would also like to implement XmlPermissionsFinder as well to use some sort of format as above.

    JT

  7. #32
    SitePoint Evangelist
    Join Date
    Dec 2003
    Location
    Arizona
    Posts
    411
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    For a library it's scope is too large. For example if you decide to add email contact to your application users where does it go? Sounds like it should go into the same user that is the authentication system. You can't though, as that is supposed to be decoupled from the rest of the system. By simply changing the authorisation system's name to Usage/UserIdentifier/Fingerprint you have restricted it's scope. Now it is something that can be attached to the user in the application (the one with an email address maybe). It also means that there can be multiple logins for a single person. Having multiple user's for a single person on the other hand just does not make sense.
    There are two ways to get around this. Have your custom User class extend this User class. So if you want to add an email address and/or other attributes you could:

    PHP Code:
    class MyUser extends User {
        var 
    $email;

        function 
    MyUser($username$password) {
            
    parent::User($username$password);
        }

        function 
    setEmail($email) {
            
    $this->email $email;
        }

        function 
    getEmail($email) {
            return 
    $this->email;
        }

    Or secondly:

    You could create a generic mechanism for dynamically attaching attributes to a user object:
    PHP Code:
    class User {
        var 
    $id;
        var 
    $username;
        var 
    $password;
        var 
    $attrs;
        var 
    $authenticated;
        var 
    $permissions;
        var 
    $roles;

        function 
    User($username$password) {
            
    $this->username $username;
            
    $this->password $password;
            
    $this->attrs = array();
        }

        function 
    authenticate() {
            
    // ... authenticate the user against the database;
        
    }

        function 
    isAuthenticated() {
            return 
    $this->authenticated;
        }

        function 
    hasPermission($name) {
            if (!isset(
    $this->permissions)) {
                
    $this->permissions = array();
                
    // ... get permissions from the database
            
    }
            return (
    in_array($name$this->permissions));
        }

        function 
    hasRole($name) {
            if (!isset(
    $this->roles)) {
                
    $this->roles= array();
                
    // ... get roles from the database
            
    }
            return (
    in_array($name$this->roles));
        }

        function 
    setAttribute($name$value) {
            
    $this->attrs[$name] = $value;
        }

        function 
    getAttribute($name) {
            return 
    $this->attrs[$name];
        }

        function 
    removeAttribute($name) {
            unset(
    $this->attrs[$name]);
        }

        function 
    hasAttribute($name) {
            return isset(
    $this->attrs[$name]);
        }

    Then you could create a custom UserFinder which extends the base UserFinder and put whatever attributes you wanted into the User object.

    JT

  8. #33
    Currently Occupied; Till Sunda Andrew-J2000's Avatar
    Join Date
    Aug 2001
    Location
    London
    Posts
    2,475
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Firstly, your root node indicates that the schema will be limited. If you use an XML document to store configuration information, you will be parsing several XML documents, which would be unnecessary overhead. You would find it much more beneficial to use a schema such as ASP.NETs Web.Config schema. This will expose many benefits for adoption...

    HTML Code:
     
    [color=black]<configuration>
    <system.web>[/color]
     
    [color=black]	[b][font=Verdana]...[/font][/b][/color]
     
    [color=black]<authentication mode="[Windows|Forms|Passport|None]">
    	<forms name="[name]" 
    		 loginUrl="[url]" 
    		 protection="[All|None|Encryption|Validation]"
    		 path="[path]" timeout="[minutes]"
    		 requireSSL="[true|false]" 
    		 slidingExpiration="[true|false]">
    		<credentials passwordFormat="[Clear|MD5|SHA1]">
    			<user name="[UserName]" 
    				 password="[password]"/>
    		</credentials>
    	</forms>
    	<passport redirectUrl="internal"/>
    </authentication>[/color]
     
    [color=black]<authorization>
    	<allow users="[comma separated list of users]"
    		 roles="[comma separated list of roles]"/>
    	<deny users="[comma separated list of users]"
    		 roles="[comma separated list of roles]"/>
    </authorization>[/color]
     
    [color=black]<identity impersonate ="[true|false]"
    		 userName="[domain\user_name]"
    		 password="[user_password]"/>[/color]
     
    [color=black]<trust level="[Full|High|Medium|Low|Minimal]" 
    	 originUrl=""/>
     
    <securityPolicy>
    	<trustLevel name="Full" policyFile="internal"/>
    	<trustLevel name="High" policyFile="web_hightrust.config"/>
    	<trustLevel name="Medium" policyFile="web_mediumtrust.config"/>
    	<trustLevel name="Low" policyFile="web_lowtrust.config"/>
    	<trustLevel name="Minimal" policyFile="web_minimaltrust.config"/>
    </securityPolicy>
    [/color]


    Defining an Administrator class is an extremely bad in terms of OOD, however as LastCraft has mentioned, you are asking for a headache unless you sit back and clearly design this.

    There are a number of components, which make up security:
    • Encryption
    • State/less (Cookies)
    • HTTP
    • Certificates (SSL)
    • ...
    Designing Authentication and Authorization simply takes on many tasks, such as a designing a Data Access Layer (DAL) as well as many other tasks. As I have found each part that makes up Authentication and Authorization adds another dependency.

    I must admit I really am not a fan of the above implementation, as it appears that things will become bloated and unethical. Why declare a class for each implementation of MySQL or XML? If this series is trying to demonstrate OO then demonstrate data abstraction and reuse. However, I think a prerequisite would be to give definitions of the terminology used. (Realm, Digest, Nonce)

    Now Authentication simply does not stand within the (Application) use of MySQL and its permissions can come into play to simplify Role Based Authentication & Authorization, which adds countless, advantages. In addition, some common scenarios in security are image verification, resolving DNS, SMTP and as a result expand the specification.

    If I can take you back a step, how are you identifying, which pages are secure and require an authentication scheme? You are already trying to implement a PermissionsFinder and skipping a number of stages prior to requiring the knowledge of any Permission. If a security scheme is required, what type of scheme should be applied, HTTP Authentication, Forms Authentication by default? Which digest will be used by default? Page level re-authentication would be required, to add security.

    Off Topic:


    Sorry, if it sounds like a rant

    Has anyone got any idea whats happening with Pears Auth_Enterprise There has never been anything published, yet the description sounds interesting...
    As the name implies, this package aims to provide an enterprise level authentication & authorization service. There are two parts to this package, the service layer which handles A&A requests and a PHP client. Support for other clients (e.g. Java, ASP/VB, etc) is possible further supporting cross-platform enterprise needs. Main features are: 1) Web Service-based 2) implements notion of a Provider which is capable of hitting a specific data store (DBMS, LDAP, etc) 3) Implements a single credential set across a single provider 4) 100% OO-PHP with the client producing a user object that can be serialized to a PHP4 session.

    Attached Images Attached Images

  9. #34
    SitePoint Evangelist
    Join Date
    Dec 2003
    Location
    Arizona
    Posts
    411
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    We are focusing our attention on Role-Based Access Control. Access to particular resources is granted based on roles and permissions associated with those roles. We have limited the scope such that authentication returns a set of permissions and the set of permissions is inspected to determine whether the user can access the resource (authorization). One desire that we have is to make the system generic enough to support several persistence mechanisms (e.g. RDBMS, XML, etc.). The goal is to illustrate the use of design patterns such as Domain Model, Data Mapper / Finder, Memento, Iterator, Factory, etc. within the context of a well-constrained problem.

    JT
    Last edited by seratonin; Apr 5, 2004 at 20:56.

  10. #35
    SitePoint Zealot oivaf's Avatar
    Join Date
    Apr 2003
    Location
    Mexico
    Posts
    138
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    A sideline: Does anyone know anything about LDAP? I thought it was designed for this kind of thing?
    I've never implemented it but googling a little tells me that yes this can be one of the uses of LDAP particularly if you want to have a central mechanism of Authentication and Access Control or for example need to use the same user/login accounts from a NT domain in your web application. I believe LDAP would be a valid storage and in fact a possible alternative of rbac.....

    As I commented before I was already working on my own version of rbac (some 4 months ago...never finished) and when thinking about how to integrate it to existing or new apps I realized that in order to follow the spec I would need to have some way of storing and/or mapping the application objects and the application users to the rbac system BUT doing so would mean a great loss in flexibility because we would force the programmer to adapt his/her app to our system.

    I think this is a critical point and this was precisely what stopped me from going on

    By reading your posts I agree that to deal with the application objects the best is to simply leave that to the application.

    Quote Originally Posted by seratonin
    Quote Originally Posted by lastcraft
    For a library it's scope is too large. For example if you decide to add email contact to your application users where does it go? Sounds like it should go into the same user that is the authentication system. You can't though, as that is supposed to be decoupled from the rest of the system. By simply changing the authorisation system's name to Usage/UserIdentifier/Fingerprint you have restricted it's scope. Now it is something that can be attached to the user in the application (the one with an email address maybe). It also means that there can be multiple logins for a single person. Having multiple user's for a single person on the other hand just does not make sense.
    There are two ways to get around this. Have your custom User class extend this User class. So if you want to add an email address and/or other attributes.....
    mmm I have to say that I don't feel very comfortable with a User class in the rbac system....why:
    1. for the reasons lastcraft exposed.
    2. I think that the user class (if it exists) would be very specific to the application and almost always used as a model for making CRUD operations in the users table, file or whatever.
    3. that functionality (adding an email address) is a different non related task I mean it doesn't have anything to do with rbac.
    4. also authentication is a very different, subject to change, and sensible part of every application IMHO.

    However I still don't see clearly how are we going to communicate with the users or store and map this information to rbac

    Quote Originally Posted by Andrew-J2000
    If you use an XML document to store configuration information, you will be parsing several XML documents, which would be unnecessary overhead.
    I think that if we ever use XML to store rbac information a caching mechanism would be devised also for any user the rbac information would be retrieved only once and then persisted in the session.

    Security is a big big part of any application with rbac we only are focusing on access control (authorization) not authentication. The idea is that you should be able to use any kind of authentication.

    Quote Originally Posted by Andrew-J2000
    Why declare a class for each implementation of MySQL or XML? If this series is trying to demonstrate OO then demonstrate data abstraction and reuse.
    maybe in order to support different storage mechanism/drivers.

    anyway will be playing with your interfaces

    l8r

  11. #36
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by Andrew-J2000
    I must admit I really am not a fan of the above implementation, as it appears that things will become bloated and unethical.
    Do you have an alternate scheme? Writing completely abstract persistence layers is a big job.

    Also you can only get reuse if it's there to be had. If you want to take advantage of complex queries and caching (likely here), they will all be quite different. You will be able to get some reuse within the storage families by inheritance (that's the advantage of the mappers, they bridge to the domain objects). At least this way it's all hidden by the Storage abstract factory.

    I like the idea of my code being unethical . Should I be struck off?

    I do agree that my Authorisor class should be something like AccessController and I should take the password out. It is more client code, but it is that little bit more decoupled as oivaf points out.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  12. #37
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    ...more suitable in how you can handle relationships.
    Exactly Sorry Marcus, but I cannot for the life of me, understand your gripe about using a database, though I've read every post

    I think for this type of data and it's relationships, XML is bad - This is not what XML was originally designed for.

    A question though Marcus, your point on storage, are you suggesting a Memento Pattern ?

  13. #38
    SitePoint Evangelist
    Join Date
    Dec 2003
    Location
    Arizona
    Posts
    411
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I was searching the Web and Binary Cloud's RBAC implementation here:

    http://webstract.org/api//__filesour...hPerm.php.html

    JT

  14. #39
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by Widow Maker
    Exactly Sorry Marcus, but I cannot for the life of me, understand your gripe about using a database, though I've read every post
    Well I may have been a bit silly . Maybe I should be struck off...

    The thing is, the point where it needs to be fast is at the point of loading the permission set. This scheme involves a five table join in a DB. It will still work though, and I guess the dataset will not be large.

    I am now thinking that a caching scheme may be the way to handle this whilst still using the RDBMS to administer things. The permission sets could be stored as serialised classes in a DBM hash for example. The cache mangement could decorate the finder.

    Quote Originally Posted by Widow Maker
    I think for this type of data and it's relationships, XML is bad - This is not what XML was originally designed for.
    I agree. I am not sure XML is the way to go for storage. However it could be a good way to configure the system, especially for testing or for bootstrapping an application. Basically a loader could parse the XML into a storage solution when it is edited.

    I think LDAP is a serious contender as it has very fast reads. RDBMS remove redundancy, but I don't see that as an issue. The main thing is that the issue can be postponed whilst things are built top-down.

    Quote Originally Posted by Widow Maker
    A question though Marcus, your point on storage, are you suggesting a Memento Pattern ?
    I was only thinking of the data transfer between the data mapper and the authentication map so far. It is still rather fuzzy until some more code is written.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  15. #40
    SitePoint Evangelist
    Join Date
    Dec 2003
    Location
    Arizona
    Posts
    411
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    Hi...



    Well I may have been a bit silly . Maybe I should be struck off...

    The thing is, the point where it needs to be fast is at the point of loading the permission set. This scheme involves a five table join in a DB. It will still work though, and I guess the dataset will not be large.

    I am now thinking that a caching scheme may be the way to handle this whilst still using the RDBMS to administer things. The permission sets could be stored as serialised classes in a DBM hash for example. The cache mangement could decorate the finder.



    I agree. I am not sure XML is the way to go for storage. However it could be a good way to configure the system, especially for testing or for bootstrapping an application. Basically a loader could parse the XML into a storage solution when it is edited.

    I think LDAP is a serious contender as it has very fast reads. RDBMS remove redundancy, but I don't see that as an issue. The main thing is that the issue can be postponed whilst things are built top-down.



    I was only thinking of the data transfer between the data mapper and the authentication map so far. It is still rather fuzzy until some more code is written.

    yours, Marcus
    I'm thinking that we do the JOIN intially and then just cache just the permission set as XML on the server in the session.

    JT

  16. #41
    SitePoint Evangelist
    Join Date
    Dec 2003
    Location
    Arizona
    Posts
    411
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Marcus,

    The more I look at your design, the more I like it.

    What about separating the Authentication from the Authorization? It would be nice to just use the Authentication component only if all I wanted to do was password protect something and didn't want to mess with a permission set.

    Also, what about telling the authenticator and/or authorizor that we would like to cache the permission set somewhere (e.g. Session)?

    Thanks,

    JT

  17. #42
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by seratonin
    The more I look at your design, the more I like it.
    Cool, but it's pure evolution and missing details. I think it is time to commit to some to code and achieve an iteration.

    Quote Originally Posted by seratonin
    What about separating the Authentication from the Authorization? It would be nice to just use the Authentication component only if all I wanted to do was password protect something and didn't want to mess with a permission set.
    I think take it one step at a time. Let's do the Authorisation first, and then add this if it seems the right thing to do in the light of day. At the moment the end point of the design is unclear to me to say the least.

    Quote Originally Posted by seratonin
    Also, what about telling the authenticator and/or authorizor that we would like to cache the permission set somewhere (e.g. Session)?
    I am afraid I have no idea right now, it's just too fuzzy. Are you familiar with MockObjects? We can build the top level without committing to persistence if you are.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  18. #43
    SitePoint Zealot
    Join Date
    Mar 2004
    Location
    Netherlands
    Posts
    138
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't want to spoil the party, but I think that you took a far too big project to start with. I even think a project of such a size can't be well managed in just a single forum thread. This project may need a whole forum for it's own...

    I must say I like the idea of collaborating on a coding project to learn design and coding techniques. I'd like to participate if there was some more structure in the organization...

    I think the best way to do something like this is start a new Sourceforge project. Sourceforge has a forum, version management, etc, just what you need. Ofcourse, it must be made clear to visitors that the main purpose for development is learning, not delivering production quality code.

  19. #44
    SitePoint Zealot
    Join Date
    Feb 2003
    Location
    Virginia
    Posts
    143
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'll publish my implementation of a RBAC, if anyone is interested. I has intergrated workflow as well. The only problem is it's coupled to my framework, so. Unless I use pear it may not FIT out of box into someone else's implementation.

    ...or exmples of implementation if that's easier.

  20. #45
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by meryn
    I don't want to spoil the party, but I think that you took a far too big project to start with.
    Maybe. I don't think that is the case as long as we avoid creeping featuritis. A single implementation (MySQL say) should only be a dozen small classes top. That is 150 lines of code total plust tests. If the project is smaller than this then nothing really gets illustrated.

    This whole thread is an experiment of course, and like all early efforts has a high risk of failure. I am happy to take a chance and it is going better than I expected already.

    Quote Originally Posted by meryn
    I think the best way to do something like this is start a new Sourceforge project.
    I agree and was going to suggest this later. I think the discussion should take place here with example snippets to explain things. I like the idea of leaving behind a tutorial on SP with the code on SF.

    A single SourceForge Project called "sitepointphp" (copyright issues - can we get permission?) or some such with one module per project would be fine. You can then explain in the project blurb that it is tutorial material and SP should be searched for the real meat.

    Sourceforge will be needed just so that fully fleshed out code and test cases can be placed somewhere, but it also adds version control. It is supposed to be a best practices thread after all .

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  21. #46
    SitePoint Evangelist
    Join Date
    Dec 2003
    Location
    Arizona
    Posts
    411
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't think that the endevour is too large now that it has been scoped. As Lastcraft mentioned, it shouldn't be more than a dozen classes and a couple hundred lines of code.

    About the Source Forge idea, I think that if we want to release code to the community then SF is a good idea. Here I think all we need to do is flesh out some of the classes in order to illustrate the patterns used and justify the choice of those patterns. We can also use this facility to ellicit feedback from other developers and hopefully go through several iterations. I guess the question comes down to: "Do we want to show and explain some of the code here or do the entire implementation and *release* it?"

    JT

  22. #47
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    On the point of BinaryCloud, after looking at the User, Perm and Auth classes, I noticed that these are accessed via Singletons, yes ?

    In my view, for the purposes of these classes, the Singleton is a bad idea - there is no real need to return only the one instance of these classes, whereby a better idea would be to use :: instead, where the class it's self isn't instantiated.

    Just seams over the top that all three classes have Singletons really - also the classes are mixing business logic (?) with SQL as well, which is breaking layering.

    What'd other members think ?

  23. #48
    SitePoint Evangelist
    Join Date
    Dec 2003
    Location
    Arizona
    Posts
    411
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Widow Maker
    On the point of BinaryCloud, after looking at the User, Perm and Auth classes, I noticed that these are accessed via Singletons, yes ?

    In my view, for the purposes of these classes, the Singleton is a bad idea - there is no real need to return only the one instance of these classes, whereby a better idea would be to use :: instead, where the class it's self isn't instantiated.

    Just seams over the top that all three classes have Singletons really - also the classes are mixing business logic (?) with SQL as well, which is breaking layering.

    What'd other members think ?
    I agree with you. It looks like most of the BinaryCloud components are accessed via Singletons. It would be interested to ask the BC developers what the rationale was for that. Having SQL in there also smells bad. I would probably use a TableGateway pattern at least.

    JT

  24. #49
    SitePoint Zealot
    Join Date
    Feb 2003
    Location
    Virginia
    Posts
    143
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have done extensive work in this area. Is it ok if I help, as I have no wish or time to manage and work a project on my lonesome?

    Anyhow, this thread turned out more informative than i expected. i thought it was just a question in general, seems it is an effort to achieve! Awesome.

    If I can help, I would like too.

    thanks

  25. #50
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by Resolution
    Is it ok if I help, as I have no wish or time to manage and work a project on my lonesome?
    Of course .

    Still trying to define the interface correctly, here is a possible acceptance test with the authentication stripped out. I have called it tests/acceptance_tests.php. Edit to taste (switch it to PHPUnit if you like)...
    PHP Code:
    <?php
    require_once('../authoriser.php');
    require_once(
    '../access_controller.php');
    require_once(
    '../authoriser_options.php');
    AuthoriserOptions::setConfigurationFile('authoriser.conf');    

    class 
    RoleBasedPermissionsTest extends UnitTestCase 
        function 
    RoleBasedPermissionsTest() { 
            
    $this->UnitTestCase(); 
        } 
        function 
    setUp() { 
            
    $authoriser = &new Authoriser(); 
            
    $authoriser->addUsage('fred'); 
            
    $authoriser->addRole('pleb'); 
            
    $authoriser->addOperation('do_stuff'); 
            
    $authoriser->attachRole('fred''pleb'); 
            
    $authoriser->permit('pleb''do_stuff'); 
        } 
        function 
    tearDown() { 
            
    $authoriser = &new Authoriser(); 
            
    $authoriser->dropUsage('fred'); 
            
    $authoriser->dropRole('pleb'); 
            
    $authoriser->dropOperation('do_stuff'); 
        } 
        function 
    testNonUserHasNothingAllowed() {
            
    $access_controller = &new AccessController();
            
    $permissions = &$access_controller->getPermissions('public'); 
            
    $this->assertFalse($permissions->can('do_stuff')); 
        } 
        function 
    testBadPasswordHasNothingAllowed() { 
            
    $access_controller = &new AccessController();
            
    $permissions = &$access_controller->getPermissions('fred'); 
            
    $this->assertFalse($permissions->can('do_stuff')); 
        } 
        function 
    testLegitimateUserHasActionAllowed() { 
            
    $access_controller = &new AccessController();
            
    $permissions = &$access_controller->getPermissions('fred'); 
            
    $this->assertTrue($permissions->can('do_stuff')); 
        } 
        function 
    testUserCannotDoNonAction() { 
            
    $access_controller = &new AccessController();
            
    $permissions = &$access_controller->getPermissions('fred'); 
            
    $this->assertFalse($permissions->can('do_unknown')); 
        } 

    ?>
    I have split Authorisor from AccessController so that the whole of the library doesn't have to be loaded just to check someone's permissions. If someone has an alternate scheme it would simplify the interface slightly to have one object instead of two.

    Here is a sample test runner...
    PHP Code:
    <?php
    define
    ('SIMPLE_TEST''/var/www/html/simpletest/');
    require_once(
    SIMPLE_TEST 'unit_tester.php');
    require_once(
    SIMPLE_TEST 'reporter.php');
        
    $test = &new GroupTest('Sitepoint advPHP RBAC');
    $test->addTestFile('acceptance_tests.php');
    $test->run(new HtmlReporter());
    ?>
    This obviously only works on my machine.

    To get this test so that it doesn't crash I have to create the files. First authoriser.php...
    PHP Code:
    <?php
    class Authoriser {
        function 
    Authoriser() {
        }
        function 
    addUsage() {
        }
        function 
    dropUsage() {
        }
        function 
    addRole() {
        }
        function 
    dropRole() {
        }
        function 
    addOperation() {
        }
        function 
    dropOperation() {
        }
        function 
    attachRole() {
        }
        function 
    permit() {
        }
    }
    ?
    Then access_controller.php...
    PHP Code:
    <?php
    class AccessController {
        function 
    AccessController() {
        }
        function 
    getPermissions() {
            return new 
    Permissions();  // Blatant fake
        
    }
    }

    class 
    Permissions {
        function 
    Permissions() {
        }
        function 
    can() {
        }
    }
    ?>
    And finally authoriser_options.php...
    PHP Code:
    <?php
    class AuthoriserOptions {
        function 
    setConfigurationFile() {
        }
    }
    ?>
    With this set up I get just one failure. This is just about the minimum amount of code I can write for RBAC to make sense. It should work as a starting skeleton at least.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things


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
  •