Also make sure phpCAS doesn't try to start a new PHP session. We have already
started our own and want to keep it :). In addition to it, it emitted a PHP
notice that could block the authentication process under certain
configurations.
And pretty much the same with the wantsurl and loginguest checks.
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().
Merged from MOODLE_18_STABLE.
The fix is wrong, as it breaks auth_db_sync_users.php and
auth_ldap_sync_users.php at least. No new users are added to Moodle, as the
username is missing from the new user info record.
The fix needs to go into update_user_record() in lib/moodlelib.php to make it
skip the 'username' key, as we really need get_userinfo() to return the
username as part of the user info array.
It doesn't make sense at all (username is not part of the externally mapped
fields) and produces a notice that breaks HTTP headers with debugging enabled.
