On 01/17/2019 09:57 AM, Anuj Borah
wrote:
Here i am not using nsUserAccount in
nsUserAccountRole as it requires 'uid' which
is not allowed in nsFilteredRoleDefinition
and nsRoleDefinition . Below are usages:
user=nsUserAccountRole(topo.standalone,'cn=tuser1,ou=People,dc=example,dc=com')
user_props={'cn':'Anuj',
'nsRoleFilter':'cn=*'}
user.create(properties=user_props,
basedn=SUFFIX)
nsUserAccountRoles(topo.standalone,
DEFAULT_SUFFIX).list()[0].dn
>>
'cn=tuser1,ou=People,dc=example,dc=com'
nsUserAccountRoles(topo.standalone,
DEFAULT_SUFFIX).create(properties=user_props)
>>> <dsdsds.nsUserAccountRole
object at 0x7fb72d259f98>
nsUserAccountRoles(topo.standalone,
DEFAULT_SUFFIX).list()[1].dn
>>>
'cn=Anuj,ou=People,dc=example,dc=com'
Let me know , what you think .
Maybe I do not understand how it works because of some lib389 magic,
but I think this is not how roles work.
You are creating cn=tuser1 and cn=Anju and they will have the role
objectclasses, but the benefit of roles is that you do NOT have to
touch the useres to assign roles to them. There is a class of users
and a class of role definitions and ONLY the change in the role
definition will determine if a user has a role or not.
Regards
Anuj Borah
> On 14 Jan 2019, at 19:28, Anuj Borah
<aborah@xxxxxxxxxx>
wrote:
>
> Hi William ,
>
> Just find out a way to do it .
This isn’t quite what I had in mind.
Remember, we should be able to compose
nsRole types to various other objects if
required (despite my dislike of nsRoles
…).
We have "nsUserAccount(Account)”, and we
need to be able to extend it with nsRole
types.
One way to achieve this is:
class nsRoleDefinition(object):
def __init__(self, instance, dn=None):
if ‘_create_objectclasses’ not in
self:
raise Exception ….
# So we must have been combined
with a type to add roles
self._create_objectclasses.append(’nsFilteredRoleDefinition’)
class nsUserAccountRole(nsUserAccount,
nsRoleDefinition):
def __init__(self, instance, dn=None):
super(nsUserAccount,
self).__init__(instance, dn)
super(nsRoleDefinition,
self).__init__(instance, dn)
Then you would use the nsUserAccountRole
like normal. (I think we may need a
similar “nsUserAccountRoles" for the
muliple search parts)
A benefit to this, is you could have
role-specific functions like
setting/changing the filter, but you never
loose the “account” features like bind.
Provided a method is uniquely sourced, I
think python takes the implementation that
is unique, or it takes the “first”. So
this should all just work.
The main benefit here is it’s really
clean, we can compose this to other types.
It also avoids any duplication of class
definitions and logic etc.
I think this is how I would like to see it
created. It may be worth making a “ticket”
just for the nsRole parts and splitting
your test for nsRoles out of the
mega-patch you have.
>
> class UserAccountnsRole(Account):
>
> def __init__(self, instance,
dn=None):
> super(UserAccountnsRole,
self).__init__(instance, dn)
> self._rdn_attribute = RDN
> self._create_objectclasses =
[
> 'top',
> 'LDAPsubentry',
> 'nsRoleDefinition',
>
'nsComplexRoleDefinition',
>
'nsFilteredRoleDefinition'
> ]
> user_compare_exclude = [
> 'nsUniqueId',
> 'modifyTimestamp',
> 'createTimestamp',
> 'entrydn'
> ]
> self._compare_exclude =
self._compare_exclude +
user_compare_exclude
> self._protected = False
>
> def _validate(self, rdn,
properties, basedn):
> if 'ntUserDomainId' in
properties and 'ntUser' not in
self._create_objectclasses:
>
self._create_objectclasses.append('ntUser')
>
> return
super(UserAccountnsRole,
self)._validate(rdn, properties, basedn)
>
>
> def create_test_user_nsrole(instance,
cn, nsRoleFilter, description,
suffix=None):
> global test_user_id
> if cn is None:
> cn = "testuser_" +
str(test_user_id)
> test_user_id += 1
> if suffix is None:
> suffix = DEFAULT_SUFFIX
> dn = "cn=" + cn + "," + suffix
> properties = {
> 'cn': cn,
> "nsRoleFilter": nsRoleFilter,
> "description": description,
> }
> user =
UserAccountnsRole(instance, dn)
>
user.create(properties=properties)
> return user
> Now just using
create_test_user_nsrole we will be able to
create entries with nsRoles.
>
>
> Regards
> Anuj Borah
>
>
>
>
>
>
> On Mon, Jan 7, 2019 at 2:30 PM
William Brown <william@xxxxxxxxxxxxxxxx>
wrote:
> Hi,
>
> I’ve been speaking to Anuj Borah
about a PR they made, and how we can
properly represent nsRole.
>
> because nsRoles are an extra
objectClass, rather than a standalone one,
we need a way to represent this properly.
>
> It’s probably a good idea to use some
of pythons composability here, where we
could do something like:
>
> class nsFilteredRole(DSLdapObject):
>
>
> class User(DSldapObject):
>
> class User_nsFilteredRole(User,
nsFilteredRole):
>
> Then to have a way to define and have
each subclass called, and asserted for
correctness. A question is how we would
handle:
>
> user = User.create(…)
> # How to convert user to
User_nsFilteredRole
>
> We could do something like:
>
> User_nsFilteredRole.from(user)
>
> And have a from that does a valid
conversion based on types and adds in the
required role parts?
>
> This isn’t a common scenario, so I
think having a limited set of well
understood types that require this type of
conversion would be okay.
>
> Thought? *looking at you Simon* :)
>
> PS: It’s good to be back
>
> --
> Sincerely,
>
> William
>
_______________________________________________
> 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
>
_______________________________________________
> 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander
|