Extension talk:MediaWikiAuth

Just a small question but where can I download the source code for this? Thanks. Primo 20:58, 21 December 2009 (UTC)
 * Unfortunately I never quite got around to getting it in a fit state for release, but it should be on Wikimedia SVN once it's cleaned up. Thanks for reminding me this needed to be done. You can use the watch feature; I'll update the attached extension page when I get it up. GreenReaper 21:57, 21 December 2009 (UTC)
 * Thanks GreenReaper, I'll do that. Primo 23:10, 21 December 2009 (UTC)

I'm also interested in this extension (as you've probably noticed on IRC ;-). --Jack Phoenix (Contact) 14:04, 30 December 2009 (UTC)


 * Will this ever get released? I'd like to use it. 87.211.219.33 20:51, 1 September 2010 (UTC)

Bugs in this extension
When I deployed this extension in my wiki, I discovered two bugs and would like to report them in case someone encounters the same problem.

First of all, on our server configuration the extension only works with uppercase user names because otherwise the check 'UPPER(rev_user_text) = \''. strtoupper( $username ). '\'', in MediaWikiAuth.php (line 82) will not work. You can fix this bug by replacing the line with 'rev_user_text = \''. $username. '\'',. However, it could then happen that some users are not checked correctly if they enter their username in lowercase letters only.

Secondly, this extension always tries to login at the external wiki first and only if this fails checks at the local database. The problem with this is that if you login in the new wiki and all your user data and preferences are imported, and you then change your password in the new wiki, you can still login with both the password from the old wiki and the updated password from the new wiki. Furthermore, in our wiki, we only wanted to import our users once during their login and afterwards no longer have a connection to the external wiki. However, this was not possible with this extension. Therefore, we inserted the following code at the beginning of the function authenticate of MediaWikiAuth.php (the code is similar to the function userExists): $dbr = wfGetDB( DB_SLAVE ); if ( $dbr->tableExists( 'user' ) ) { $res = $dbr->select(		'user',		array( 'user_id' ),		array( 'user_name' => $username ),		__METHOD__	); $row = $dbr->fetchObject( $res ); if ( $row ) { $this->old_user_id = $row->user_id; $dbr->freeResult( $res ); return false; }	$dbr->freeResult( $res ); } Hopefully this helps someone. --93.210.17.235 20:37, 14 July 2011 (UTC)
 * Your comments are . . . confusing. The "upper" test is saying to the database "take the username from the table, convert it to uppercase, and then compare it to [the entered username, converted to uppercase]". There should be no need for usernames to be uppercase to start with. As for "not logging in users with changed passwords", authenticate should only be called by MediaWiki if the user does not exist locally - which it should, as it is created after you log in remotely. GreenReaper 21:23, 14 July 2011 (UTC)


 * I can only say that the extension did not work until I changed that line so that the user names were not converted to uppercase. I am not sure if this is the actual problem but at least the extension then worked on our wiki. In any case, by changing the line you also match the function userExists to the function checkImportableUser in SpecialUserLogin.php because there the user names are not converted into uppercase.
 * The second problem is because of the function checkPassword in includes/User.php. This function always calls authenticate before the function this::comparePasswords which checks the local password. Therefore, the extension always queries the other wiki, no matter if a user is already imported or not. By returning from authenticate early if the user has already been imported, one can fix this problem.
 * However, I do have to say that I am not that experienced with MediaWiki programming and that your extension works perfectly, except for these two glitches.
 * --93.210.15.17 15:53, 15 July 2011 (UTC)
 * It seems you are right! I wonder if that changed in 1.16/7, or if was just something I overlooked. Thanks for sharing your solution. GreenReaper 19:45, 15 July 2011 (UTC)