[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
back-passwd (Was: ITS#40 )
I've committed a set of changes based upon your patches.
The scope handling needed some minor improvement. I
also modified the codes to use dn_*() and rdn_attr_*()
routines and fix a couple of minor bugs.
>Addressing the problems in the original message:
>1) The DN returned is of the form cn=pw_name, SUFFIX.
I left DN uid=pw_name.
The rdn attribute type could be configuration item.
>2) The uid attribute is gone.
Added it back in. Also assigned cn=pw_name and sn=pw_name
because cn,sn are both required attributes of person.
>3) The GECOS field is parsed for cn and sn fields. The BSD usage of '&'
>in the GECOS field is recognized. The cn is terminated at the
>first ',' in the GECOS. The sn is only shown if there is a space in the cn,
>in which case the tail of the cn is used as the sn.
Left this alone.
>For the suggested changes:
>1) I left the objectclass as person. Perhaps posixAccount would be more
>appropriate
person is painful as it requires cn & sn attributes.
objectclass(es) could be a configuration item.
> this is only a demo backend.
That's very true. It also serves as a "get your feet wet" backend
for would-be slapd hackers.
>2) The DN is hardcoded to use cn=
See above.
>3&4) The full name is processed, the description attribute contains the raw
>contents of the GECOS field.
Looks good.
>5) There isn't enough agreement on usage of the rest of the GECOS field to
>warrant this.
Agreed.
>6) didn't do it.
>7) didn't do it.
>
>Some other fixes: I added an entry for the base of the backend itself, which
>is just an organizationalUnit. Also, I added a check to prevent searches
>within this backend from nesting endlessly. (E.g., in the original code,
>given the backend at ou=passwd; a onelevel or subtree search based at
>cn=root,ou=passwd would return the same results as a onelevel or subtree
>search based at ou=passwd. And so on and so on...)
I modified the code such that a one/sub search at the suffix would
return the suffix entry and passwd entries (if they passed the filter).
I also added some additional error handling.
Also, as base and suffix are normalized (uppercase) DNs, I tolowerred
the username during a 'base' search for an entry.
And I added 'make passwd' in ldap/tests. For now, it just does
a few searches using the local password file. See test-db/ldapsearch.out
for results. Test inputs (data/passwd) and outputs (data/passwd.out)
need to be written.
- Kurt