Grzegorz Czuba wrote:
First, I'd like to appologize if my post seems offesive. I'm not feeling
too good today...
> Please count number of files that require modification in this scenario.
> I think that this number will be more than 1. :)
>
> 4.
> >>Only one file needs to be changed to make read-only LDAP roles/permissions
> >>possible, which is Role class.
>
> Sorry, I think you are wrong.
Oh really?! ;-)
>
> Other classes in Turbine depend on current implementation of Roles and
> Permission.
> As an example please look for RolesSet or PermissionSet.
And what do you think needs to be changed in these?
>
> /////////////////////////////////////////////////////////////
>
> Now I think that all agree that files listed bellow is a minimal subset in a
> successful implementation of authorization based on LDAP
> turbine\om\security\DefaultAccessControl.java
This is DB based implementation. why would you like to change it?
> turbine\om\security\Permission.java
Permission does not depend on any DBStuff. No need to change it.
> turbine\om\security\Role.java
OK, Peer references have to go away. (will break admin stuff)
>
> And now my new question.
>
> PermissionSet, RoleSet and other places in Turbine uses Role And Permission
> object.
What is the difference between Role/Permission implementation depending on
the backend data source that you are pursuing here? When all datasource
interaction is performed by AccessControlBuilder implementation, I don't
see why there should be any.
> Should LDAP version be created by extending existing classes or by using new
> interfaces?
>
> 1) public class LdapPermission extends Permission
> 2) public class LdapPermission implements Permission
>
> I vote for second solution.
If we needed that, it would be the right choice, but I think that we don't.
> 1. New Permission interface (identical to existing class Permission)
> 2. New Role interface
> 3. Existing Role class should be renamed to DefaultRole
> 4. Existing Permission class should be renamed to DefaultPermission
> 5. Modification in PermissionPeer.java
> from
> Permission obj = new Permission();
> to
> Permission obj = (Permission) new DefaultPermission();
>
> 5. modification in RolePeer.java
> from
> Role obj = new Role();
> to
> Role obj = (Role) new DefaultRole();
>
> And now all works like previously.
I believe that all of this is not needed (see above).
I have a question for you: Have you thought about what structure should
or data in LDAP have? What classes/attributes should the objects have?
We probably need to define some custom classes. I have little LDAP
knowledge, so I don't know what are the proper procedures here.
Rafal
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
