Last modified: 2009-09-27 22:54:26 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 9398 - accounts created by admins should be autoconfirmed by default
accounts created by admins should be autoconfirmed by default
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
User login and signup (Other open bugs)
unspecified
All All
: Normal enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-23 05:56 UTC by Yonatan Horan
Modified: 2009-09-27 22:54 UTC (History)
5 users (show)

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


Attachments

Description Yonatan Horan 2007-03-23 05:56:21 UTC
I think the title pretty much explains it. Right now, when I create an account
as an admin it isn't autoconfirmed and I need to wait 4 days for it to be
autoconfirmed. I don't see a reason why accounts created by admins shouldn't do
this automatically.
Comment 1 Aaron Schulz 2007-03-23 06:46:10 UTC
"Autocomfirmed" is on-demand right, it is not stored directly. Some groups
automatically have it, but it would be somewhat difficult to trace back to who
made the account in an efficient way.
Comment 2 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-03-23 17:54:08 UTC
In the current setup, yeah.  We would need to store what usergroup made the user, or something.  
(Or maybe, and I'm being evil here, we could store 'autoconfirmed' sometimes explicitly and 
sometimes implicitly . . . but that would be evil.)
Comment 3 Steve Sanbeg 2007-03-23 18:11:16 UTC
I'm not entirely sure I follow the reasoning here.  Why would admins need to
create accounts?  If it's a moderated wiki, where all accounts are created by
admins, they could just change the autoconfirm time or give everyone access to
move/create.  If it's a foundation wiki where they're just creating accounts for
visually impaired users who can't pass the capcha, they should be able to wait.

It would be possible to have a confirmed group with equivalent privs that could
be set manually.  That would be a little less messy, since it wouldn't need a
software change, or take way the ability of an admin to create a non-confirmed
account.
Comment 4 Yonatan Horan 2007-03-23 19:48:42 UTC
Admins create accounts all the time on different wikis and there's no reason for
the users they create not to be autoconfirmed. For example, yesterday I created
a bot account on the commons but couldn't start a test run since the captcha
screen kept popping up. It is a very low priority bug, but a bug nonetheless.
Comment 5 Rob Church 2007-06-11 06:50:48 UTC
"autoconfirmed" is a permission given to users whose accounts are older than $wgAutoConfirmAge and who have more than $wgAutoConfirmEdits. These are determined based on the user.user_registration and user.user_editcount columns.

Since it wouldn't be appropriate to insert bogus data into the user table, we'll either have to introduce a new column and another "confirmed" right, or think up some clever alternative.
Comment 6 ais523 2007-06-11 10:12:06 UTC
On enwiki at least, the most common reason for an admin to create an account is either that they're bypassing a CAPTCHA for an anon who wants an account who can't solve it for some reason, or that they're bypassing AntiSpoof for an anon who wants an account in a situation where either it's a false-positive, or the similar username looks unlikely to be used (and therefore the risk of confusion is low). In neither of these cases would autoconfirmed-by-default be desirable; either the solution in comment #3 (the ability for admins to accelerated-autoconfirm any user) or at least disabling this feature for accounts created 'by email' would be better.
Comment 7 slakr 2007-06-11 10:47:56 UTC
It's also important to consider the following scenarios.  I'm not saying these are 100% _going to happen_, but I think it's worth noting since nobody's said them before, and they're very plausible scenarios:

Regarding auto-confirming accounts created by admins:

1.  "John" exists in real life.
2.  "Sally," a psychopath, decides to find ways to spam John into oblivion because John took the last Coke from the soda machine.
3.  Sally asks an admin to add an account for her (email: john@john.com) on "YourWiki."
4.  Since the address is, as you are proposing, already confirmed, Sally and/or anyone else can spam John's mailbox via YourWiki-- especially if Sally starts posting highly inflammatory things on various articles or discussions.
5.  John, instead of using the forgotten password link, reports YourWiki for spamming to "RandomRBL," because he never opted-in to receive email from YourWiki; and, seeing as lack of opt-in is one of the easiest ways to get RBLed...
6.  RandomRBL blocks YourWiki's IP range.
7.  Any user that uses an ISP that adds "RandomRBL" to their SpamAssassin criteria  ends up sending all legitimate emails from actual users to their junk mail folders.
8.  You spend hours on the phone and/or a dozen or so emails trying to convince RandomRBL to unblock YourWiki's IP ranges, and those users that those ISPs will complain about not having received email notifications.

An simpler alternative scenario might involve "Michael," who hates YourWiki with a passion, doing something similar; but, instead giving your admin spamtrap@somerandomdomain.com as his email address.  This will accomplish the same thing if YourWiki's class C sends more than one similar spam mail to the spamtrap-- all of which is easily accomplished by the spammer enabling email on the account and sending what would look like spam to the spamtrap.  For all intensive purposes, YourWiki would end up being equated with an open formmail relay, and would almost certainly be blocked.


In a nutshell, it's a bad idea to blanket auto-confirm an email address that is allegedly the user's without knowing definitively that the user has access to that email address. 
Comment 8 ais523 2007-06-11 10:58:26 UTC
(In reply to comment #7)
> It's also important to consider the following scenarios.  I'm not saying these
> are 100% _going to happen_, but I think it's worth noting since nobody's said
> them before, and they're very plausible scenarios:
> Regarding auto-confirming accounts created by admins:
> 1.  "John" exists in real life.
> 2.  "Sally," a psychopath, decides to find ways to spam John into oblivion
> because John took the last Coke from the soda machine.
> 3.  Sally asks an admin to add an account for her (email: john@john.com) on
> "YourWiki."
> 4.  Since the address is, as you are proposing, already confirmed, Sally and/or
> anyone else can spam John's mailbox via YourWiki-- especially if Sally starts
> posting highly inflammatory things on various articles or discussions.
You've misunderstood the meaning of 'autoconfirmed' (which is quite different from 'emailconfirmed'!). 'autoconfirmed' allows a user to edit semi-protected pages (and on some wikis, the permission is required to reupload images over existing images, to rename pages, and/or to patrol edits); it has nothing to do with email. The scenario you suggest breaks down at step 3; suppose Sally turns up at [[w:en:WP:ACC]] and requests the email, and I answer the request; then John will get a message saying something like 'Someone (probably you) requested an account on en.wikipedia; if this is you, please log on with such-and-such a password...' and John will ignore it (and possibly misinterpret it as a phishing request, but whether John does or not is irrelevant). The email-this-user feature is at that point not enabled (for an example, see <http://test.wikipedia.org/wiki/Special:Emailuser/Account_Ais523_made_to_test_account_creation_1>; I'm not an admin on testwiki, but it wouldn't make a difference if I were, and I created the account as an example for this bug (I'm going to ignore the confirmation email it sends me).)
Comment 9 Cenarium 2009-09-27 22:54:26 UTC
presumably fixed with the confirmed usergroup created in bug 19611

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


Navigation
Links