Last modified: 2013-06-18 15:25:34 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T13148, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 11148 - Users can login with global account and create an account in a wiki even if IP is blocked from account creations
Users can login with global account and create an account in a wiki even if I...
Status: VERIFIED FIXED
Product: MediaWiki extensions
Classification: Unclassified
CentralAuth (Other open bugs)
unspecified
All All
: Normal normal with 14 votes (vote)
: ---
Assigned To: Victor Vasiliev
: patch, patch-need-review
: 16058 22063 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-01 23:36 UTC by Rotem Liss
Modified: 2013-06-18 15:25 UTC (History)
12 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Patch (2.05 KB, patch)
2007-11-25 13:43 UTC, Rotem Liss
Details

Description Rotem Liss 2007-09-01 23:36:13 UTC
Let's say a certain IP is blocked from account creations in wiki A. A user may register a (global) account in wiki B, then log in with it in wiki A. Preferably, he won't be allowed to do that.

Also, the user silent registration is not logged in Special:Log/newusers, i.e. the hook AddNewAccount does not run. It should do.
Comment 1 Aaron Schulz 2007-09-02 00:28:39 UTC
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. 
Comment 2 Rotem Liss 2007-09-02 01:44:18 UTC
(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.)
Comment 3 Rotem Liss 2007-09-02 03:21:48 UTC
(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.
Comment 4 Rotem Liss 2007-11-25 13:43:35 UTC
Created attachment 4381 [details]
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.
Comment 5 Mike.lifeguard 2008-10-21 01:14:41 UTC
*** Bug 16058 has been marked as a duplicate of this bug. ***
Comment 6 spacebirdy 2008-11-23 21:54:57 UTC
If You don't want to implement this for some reason, how about creating a new blockoption:

[x] 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.
Comment 7 Max 2009-03-10 07:04:18 UTC
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!
Comment 8 Andrew Garrett 2009-03-10 07:08:29 UTC
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;
		}
Comment 9 Mike.lifeguard 2009-03-10 12:17:33 UTC
(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.
Comment 10 James Alexander 2010-01-13 07:27:50 UTC
*** Bug 22063 has been marked as a duplicate of this bug. ***
Comment 11 James Alexander 2010-01-13 07:29:41 UTC
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 :(
Comment 12 James Alexander 2010-01-20 08:57:10 UTC
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.
Comment 13 Sumana Harihareswara 2012-02-17 14:51:21 UTC
Is this issue still reproducible?  Are people still having this problem?  Thanks.
Comment 14 Martijn Hoekstra 2012-03-12 13:51:31 UTC
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)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links