On 01/17/2019 09:57 AM, Anuj Borah wrote:
Hay William.
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 Tue, Jan 15, 2019 at 6:30 AM William Brown <wbr...@suse.de
<mailto:wbr...@suse.de>> wrote:
> On 14 Jan 2019, at 19:28, Anuj Borah <abo...@redhat.com
<mailto:abo...@redhat.com>> 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
<will...@blackhats.net.au <mailto:will...@blackhats.net.au>> 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@lists.fedoraproject.org
<mailto:389-devel@lists.fedoraproject.org>
> To unsubscribe send an email to
389-devel-le...@lists.fedoraproject.org
<mailto:389-devel-le...@lists.fedoraproject.org>
> 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@lists.fedoraproject.org
> _______________________________________________
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
<mailto:389-devel@lists.fedoraproject.org>
> To unsubscribe send an email to
389-devel-le...@lists.fedoraproject.org
<mailto:389-devel-le...@lists.fedoraproject.org>
> 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@lists.fedoraproject.org
_______________________________________________
389-devel mailing list -- 389-devel@lists.fedoraproject.org
<mailto:389-devel@lists.fedoraproject.org>
To unsubscribe send an email to
389-devel-le...@lists.fedoraproject.org
<mailto:389-devel-le...@lists.fedoraproject.org>
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@lists.fedoraproject.org
_______________________________________________
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
--
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
_______________________________________________
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
