internal package
Foswiki::Users::LdapPasswdUser
Password manager that uses Net::LDAP to manage users and passwords.
Subclass of
Foswiki::Users::Password
.
This class does not grant any write access to the ldap server for security reasons.
So you need to use your ldap tools to create user accounts.
Configuration: add the following variables to your LocalSite.cfg
- $Foswiki::cfg{Ldap}{server} = <ldap-server uri>, defaults to localhost
- $Foswiki::cfg{Ldap}{base} = <base dn> subtree that holds the user accounts e.g. ou=people,dc=your,dc=domain,dc=com
new($session) -> $ldapUser
Takes a session object, creates an
LdapContrib object used to
delegate LDAP calls and returns a new
Foswiki::User::LdapPasswd object
error() -> $errorMsg
return the last error during LDAP operations
writeDebug($msg)
Static method to write a debug messages.
fetchPass($login) -> $passwd
this method is used most of the time to detect if a given
login user is known to the database. the concrete (encrypted) password
is of no interest: so better use userExists() for that
userExists($name) -> $boolean
returns true if the login or wikiname exists in the database;
that's performing better than fetching the password and then
see what comes out of this
checkPassword($login, $password) -> $boolean
check passwd by binding to the ldap server
readOnly() -> $boolean
we can change passwords, so return false
isManagingEmails() -> $boolean
we are managing emails, but don't allow setting emails. alas the
core does not distinguish this case, e.g. by using readOnly()
getEmails($login) -> @emails
emails might be stored in the ldap account as well if
the record is of type possixAccount and inetOrgPerson.
if this is not the case we fallback to twiki's default behavior
finish()
Complete processing after the client's HTTP request has been responded.
i.e. destroy the ldap object.
removeUser( $user ) -> $boolean
LDAP users can't be removed from within the engine.
So this will call the deleteUser interface of the secondary
password manager only
Returns 1 on success, undef on failure.
passwd( $user, $newPassword, $newPassword ) -> $boolean
TODO: API missmatch
This method can only change the LDAP password. It can not
add the user to the LDAP directory. To change the password the
old password must always be correct. There's no mode to force the
change irrespective of the existing password.
In any other case the secondary password manager gets the job.
encrypt( $user, $passwordU, $fresh ) -> $passwordE
LDAP can't encrypt passwords. But maybe the secondary
password manager can.
setPassword( $login, $newPassU, $oldPassU ) -> $boolean
If the $oldPassU matches matches the user's password, then it will
replace it with $newPassU.
If $oldPassU is not correct and not 1, will return 0.
If $oldPassU is 1, will force the change irrespective of
the existing password, adding the user if necessary.
Otherwise returns 1 on success, undef on failure.
setEmails($user, @emails)
Set the email address(es) for the given username.
The engine can't set the email stored in LDAP. But may be the secondary
password manager can.
findUserByEmail( $email ) -> \@users
-
$email
- email address to look up
Return a list of user objects for the users that have this email registered
with the password manager. This will concatenate the result list of the
LDAP manager with the secondary password manager
canFetchUsers() -> boolean
returns true, as we can fetch users
returns a
Foswiki::ListIterator of loginnames