If the user specifies the same LDAP search context more than once,
when we sync users we retrieve the same set of users twice. When we
try to insert the "duplicated" user in the temp table again, the db
barfs and the db layer aborts the whole transaction.
So we try to detect and remove duplicates. This is a bit tricky (LDAP
is such a complex and wonderful protocol) as the contexts are
distinguished names and the matching/comparison rules are complex. But
assuming that we only use the attribute types used in 99.999% of the
distinguished names used for contexts out there (that is: dc, ou, cn,
o, l and c), and also assuming that the user is not using different
encodings/escapings for the same context, we can lower case the
contexts to compare them (and remove duplicates).
This is safe according to RFC-4517 (section 4.2.15. distinguishedNameMatch)
and RFC-4519 (where the EQUAILITY property is defined for the
different user application attribute types).
This shouldn't break any configuration that wasn't broken before :)
Signed-off-by: Iñaki Arenaza <iarenaza@mondragon.edu>
It looks like array_change_key_case() does not work recursively, so we
were not actually lowercasing the expiration attribute key. As the
configuration setting is always lowercase they didn't match.
From 2.0 on we lowercase all the settings related to LDAP attributes
to cope with differences in LDAP servers when returning attribute
names as array indices (some lowercase them, some leave them as
specified in the query, some normalize them, etc.).
But we only lowercase them when saving the settings page. So on sites
that have been migrated from 1.x, it may happen that we still have
mixed-case attribute names. And this is fatal for the user_attribute
setting, as we might not detect it in the returned array from LDAP and
it will be empty (and the db layer throws and exception).
So we just make sure the attribute name is lowercased (and trimmed,
in case it's got some white space around it).
Signed-off-by: Iñaki Arenaza <iarenaza@mondragon.edu>
We need to specify a valid user id in the call to role_assign(). And we only
have to make the call if the user has been added successfully, not
otherwise.
Also make sure we lowercase the memberuser and group distinguished names
before comparing them. Depending on the LDAP server we can get mixed case
values for the DNs, and the user may have specified the creators group/ou
name in a different case.
By the way, this has been broken for ages (since the auth cleanup in 1.8, in
2007!). It's a bit strange nobody noticed before :-O
Credit goes to Joe Chryst.
They now share most of the code again, this time via subclassing, and they
share some code with enrol/ldap. They have also gained some features and a few
fixes.
As authentication and enrolment plugins now have a version number, the LDAP
version number setting was "shadowed" by the plugin version number. So we
rename the LDAP setting name to ldap_version, et voila!
AMOS START
REM fixed $a[] in [auth_dbdeleteuser, auth_db]
REM fixed $a[] in [auth_dbinsertuser, auth_db]
REM fixed $a[] in [auth_dbreviveduser, auth_db]
REM fixed $a[] in [auth_dbsuspenduser, auth_db]
REM fixed $a[] in [auth_dbupdatinguser, auth_db]
AMOS END
Both CAS and LDAP auth plugins open new connections to the LDAP server
to get the user account details. While this is the desired behaviour
for regular logins (we probably don't have an already open connection
to the LDAP server), this is a ressource hog when we are doing user
synchronization, as the closed connections remain in the TCP_WAIT
state for a while before the server can reuse them. If we are syncing
a lot of users, we can make the server run out of available TCP
ressources.
So we cache the connection the first time we establish it and return
the same connection handle everytime, unless we've closed all the
'open' connections, or the auth object is destroyed.
In addition to that, there were a few missing calls to ldap_close().
These include:
MDL-14078: redirect() doubles the specified timeout when we haven't printed
the page header and uses javascript to execute the redirect. This
is interacting badly with some versions of IE and FF (at least
3.0.x Windows version) that fireup javascript timers even if
we already left the page where we set those up. Just print
the page header (we are printing other content anyway) to
make redirect respect our timeouts.
MDL-14071: All the relevant details are in the description of the bug :)
MDL-14297: This is probably the same as MDL-14078
Tim Lock