Does CentralAuth check the IP/blocked status of a user? I seems to take the name/password. I suppose the IP still couldn't edit on wiki A. But account creation blocks should be enforced.

I'm not sure if we want all blocks to be global, I know that $wgAuth does create/init a local user account, and so perhaps that aspect could be stopped if an IP is account-creation blocked.

rotemliss wrote:

(In reply to comment #1)

Does CentralAuth check the IP/blocked status of a user? I seems to take the
name/password.

When logging into an account that doesn't exist (in the local wiki), MediaWiki checks the authentication plugin (CentralAuth is an example). If the plugin is configured to automatically create the account (CentralAuth is) *and* the user is exist with the supplied password in the plugin (i.e. in the global database), the account is automatically created locally. This should be conditional (do that only if not blocked), and also run the hook AddNewAccount.

I suppose the IP still couldn't edit on wiki A.

Using the default block options, logged-in users can edit, and account creations are disabled. This way, account creations block can be easily bypassed.

But account creation blocks should be enforced.

I'm not sure if we want all blocks to be global, I know that $wgAuth does
create/init a local user account, and so perhaps that aspect could be stopped
if an IP is account-creation blocked.

That's the most reasonable solution.

From the technical point of view, the current silent account creation method (after login) skips all the permission checks (in LoginForm::addNewAccountInternal), which is used both in the account via mail and in the regular account creation, and calls directly to LoginForm::initUser, which does the actual addition of the user. I think most of the function LoginForm::addNewAccountInternal *is* useful, since it checks if the database is read only, checks if the user is allowed to create accounts (BTW, this also fixes the problem of wikis with restricted accounts (e.g. wikimediafoundation): users should have the permission to create an account if they try to log in) and checks blocks. The non-useful features (wgAuth->addUser, and maybe captcha) can be disabled via an additional parameter (autocreate) to LoginForm::addNewAccountInternal, like the one of LoginForm::initUser. Thus, the appropriate part of LoginForm::authenticateUserData should call LoginForm::addNewAccountInternal(autocreate = true) rather than LoginForm::initUser, and the hook "AddNewAccount" should be added after this call for Newuserlog et al. (This problem should actually be fixed in the core code, not in the extension, since it's a problem for all the authentication plugins.)

rotemliss wrote:

(In reply to comment #2)

and the hook "AddNewAccount" should be added after this
call for Newuserlog et al.

Note that CentralAuth itself uses "AddNewAccount" hook to add the new user to "localnames" (the function CentralAuthPlugin::initUser adds the new user to "localuser" afterwards). I don't know if it's problematic to add the hook, then.

rotemliss wrote:

Patch

This patch does what I suggested. About the hook AddNewAccount used by CentralAuth: The new user *should* be added to localnames (if the global user is deleted, it should be shown in Special:MergeAccount), and thus running the hook fixes another small bug.

Attached:

mike.lifeguard+bugs wrote:

*** Bug 16058 has been marked as a duplicate of this bug. ***

spacebirdy wrote:

If You don't want to implement this for some reason, how about creating a new blockoption:

• allow automatic account creation (or reword it, if it sounds bad)

and have that checked by default, so sysops can uncheck it only in the severe cases where this is abused.

Thanks for Your time.

malest wrote:

I suggest autochecking if the same IP is blocked in Wiki "A" and "B" (using the nomenclature from the initial bug report) and when it is, allow the account creation in Wiki "A"! I am personally blocked from en.wikipedia because I'm behind a big university proxy even at home and can't create an account anywhere. I think my IP is blocked in almost every wikimedia project (but I already have an accont at de and commons), and I think if I have a trusted account in one of them I should be able to open one everywhere. This would definitely save some admin time.
Excuse my bad English and thanks for all the great work!

This seems to have been fixed

		$anon = new User;
		if ( !$anon->isAllowedToCreateAccount() ) {
			// Blacklist the user to avoid repeated DB queries subsequently
			// First load the session again in case it changed while the above DB query was in progress
			wfDebug( __METHOD__.": user is blocked from this wiki, blacklisting\n" );
			$session = CentralAuthUser::getSession();
			$session['auto-create-blacklist'][] = wfWikiID();
			CentralAuthUser::setSession( $session );
			return false;
		}

mike.lifeguard+bugs wrote:

(In reply to comment #7)

I suggest autochecking if the same IP is blocked in Wiki "A" and "B" (using the
nomenclature from the initial bug report) and when it is, allow the account
creation in Wiki "A"! I am personally blocked from en.wikipedia because I'm
behind a big university proxy even at home and can't create an account
anywhere. I think my IP is blocked in almost every wikimedia project (but I
already have an accont at de and commons), and I think if I have a trusted
account in one of them I should be able to open one everywhere. This would
definitely save some admin time.
Excuse my bad English and thanks for all the great work!

That's unrelated and probably a bad idea. When wiki A blocks account creation on an IP (range) then it should be blocked, full stop. What wiki B has or has not done with respect to account creation on the same IP (range) is irrelevant. Submit a new bug if you must.

• Bug 22063 has been marked as a duplicate of this bug. ***

I'm leaving this as resolved at the moment but thats just because I'm not sure if its still waiting to be checked? I filed another version of this yesterday because we're still having the same problem :(

Feel free to revert me if I'm wrong but I think I'm going to reopen this. I'm not sure if this patch has been checked but it has been sitting here as resolved and fixed for months now and it is definitely still happening an causing problems on an almost daily basis. It would be great to have it looked at again if possible.

sumanah wrote:

Is this issue still reproducible? Are people still having this problem? Thanks.

I have been unable to reproduce this bug:

Reproduction steps:
My public IP is 178.85.34.6
I blocked this IP locally on en.wikipedia.org, with settings anon-only, account creation blocked and autoblock disabled
I logged out
I verified that account creation is blocked on en.wiki by trying to create the account bugzilla11148 locally on en.wiki
I tried creating that same accountname on simple.wiki
I tried logging in to de.wikipedia.org
I tried logging in to en.wikipedia.org

expected:
Account manually created on simple
confirmed: 13:34, 12 March 2012 Bugzilla11148 (talk | changes) created a user account
Attempted login to a different project wil create an account on that project, apart from en.wiki
confirmed: attempted login to de.wikipedia.org succesfull
confirmed: attempted login to en.wikipedia.org failed, with the account creation blocked message

I think that means we can close this bug as resolved. Ideally the software should indicate that it tried to automatically create an account, but failed because of the block. This is however a very small issue. I'll discuss if it's worth opening a separate bug for.

Boldly setting status to resolved (per this testcase), fixed (per comment 8)