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)

1.18
Does this extension work in 1.18/1.19? -- Prod (talk) 01:55, 17 April 2012 (UTC)


 * Don't know. Have you tried it? :-)
 * I'm moving to 1.19 soon, so if it doesn't, I'll probably want to fix it then. GreenReaper (talk) 01:57, 17 April 2012 (UTC)
 * Looking through the patch file, it looks like the only section that can't be merged anymore is function mailPassword, since that appears to no longer exist. I'll try to test it soon, but gotta figure out what else has broken with the updates :). -- Prod (talk) 02:13, 17 April 2012 (UTC)

I got the following error:
 * PHP Notice: unserialize: Error at offset 0 of 9 bytes in /.../w/extensions/MediaWikiAuth/MediaWikiAuth.php on line 134, referer: http://.../w/index.php?title=Special:UserLogin&action=submitlogin&type=login&returnto=Special:Login. -- Prod (talk) 05:25, 22 April 2012 (UTC)
 * This actually appears to be Wikia blocking snoopy at the cache level. Change the line in MediaWikiAuth.php starting  to something else.
 * I suggest  so they can be specific if they really want to block people. GreenReaper (talk) 06:35, 26 June 2012 (UTC)

OAuth
Probably should be deprecated in favor of Extension:OAuthAuthentication these days? That one does not require core patches nor sharing passwords. (It does require OAuth to be installed on the remote wiki, though.) --Tgr (WMF) (talk) 15:03, 24 June 2015 (UTC)


 * In some cases, OAuth may be a more suitable solution than this extension. However, the original goal was to ease the migration of a community from one wiki host to another, especially in the cases where the original host is not particularly interested in easing this transition.


 * Passwords are required because you want to create a real account on the new host so that you are no longer reliant on the original host; after they login once, MediaWikiAuth is done and in the future they will use the regular login path.


 * The core patches are for more comprehensive error messaging, which appeared to not be an option at the time of development; the best solution would be to provide a way for extensions to provide specific error messages on login failure, or to modify this extension to use such a system if it now exists. GreenReaper (talk) 15:15, 24 June 2015 (UTC)