Last modified: 2010-05-15 15:37:24 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 2065 - proposal to allow creation of new accounts only after e-mail address confirmation
proposal to allow creation of new accounts only after e-mail address confirma...
Status: RESOLVED WORKSFORME
Product: MediaWiki
Classification: Unclassified
User login and signup (Other open bugs)
1.5.x
All All
: Normal enhancement with 4 votes (vote)
: ---
Assigned To: Tobias McNulty
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-03 19:13 UTC by T. Gries
Modified: 2010-05-15 15:37 UTC (History)
5 users (show)

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


Attachments
(optionally) requires e-mail confirmation prior to page editing on new accounts (1.51 KB, patch)
2006-02-07 04:57 UTC, Tobias McNulty
Details

Description T. Gries 2005-05-03 19:13:51 UTC
Account creation requires e-confirmed address

Obviously not for Wikipedia use, but a configurable option like

   $wgAccountcreationRequiresConfirmedAddress

could be nice for wikis where the administrator feels the need for a tighter
control of the userbase -- contributed by User Wegge. New accounts can then only
be successfully created after first having the e-mail address confirmed.

So, he meant, that the account creation is somehow delayed, the account is not
opened unless the user has confirmed the e-mail address.
Comment 1 JeLuF 2005-05-03 19:23:31 UTC
Can we please add a new severity class to bugzilla? "unwiki" for things that
violate the wiki spirit?

Verifying the email address provides NO control at all. There are dozens of
providers of free email accounts.

See also http://www.usemod.com/cgi-bin/mb.pl?PublicAccount
Comment 2 Chris 2005-05-30 14:41:47 UTC
> Verifying the email address provides NO control at all.

And yet, it's been a very valid and simple form of security for the 
messageboard system we use (200,000+ users and counting) and has been very 
effective at stopping random spammers and flamers, which used to be a big 
problem.

I'd very much like to see this supported.
Comment 3 Rowan Collins [IMSoP] 2005-05-30 14:58:11 UTC
(In reply to comment #2)
> And yet, it's been a very valid and simple form of security for the 
> messageboard system we use (200,000+ users and counting) and has been very 
> effective at stopping random spammers and flamers, which used to be a big 
> problem.

I guess it works in that it places a form of "speed bump" or "prickly hedge"
[http://www.usemod.com/cgi-bin/mb.pl?PricklyHedge] - while it doesn't actually
*prevent* people from doing something, it *discourages* those who aren't
particularly committed to doing so. The questions leading inevitably from that are:
* does it discourage enough people - or maybe too many?
* is the set of people discouraged by the "hedge" the same set of people who
would be a nuisance?
* is it, in general, the most effective solution to the problem in hand?

The answers to those questions will of course vary between individual cases, but
a lot of people feel that wikis are successful precisely because they *don't*
have such restrictions, and certainly on Wikipedia, suggestions such as
[[m:Anonymous users should not be allowed to edit articles]] are generally shot
down pretty quickly (see also the parody, [[m:Friends of gays should not be
allowed to edit articles]], which satirically makes the point about accurately
identifying your "target"). 

Whether it would *ever* be the right answer, I'm not sure - certainly such a
site would feel a little less like a "real" wiki, but maybe there's room in the
world for such sites...
Comment 4 T. Gries 2005-10-31 08:00:28 UTC
After reconsidering the posting and the comments I suggest to close this bug as
"WONTFIX".
Comment 5 David Taylor 2005-11-09 19:02:31 UTC
It's ironic that people are bashing this idea as 'unwiki':
In order to submit a bug to bugzilla, you have to create an account, 
which sends your password to the e-mail address you specify.

I'm not sure how that process differs from this proposal...

I would call this a good idea, but I don't think it prevents bots 
very effectively, which I think is likely to become a more long-term 
pressing concern than vandalism.

 
Comment 6 Rowan Collins [IMSoP] 2005-11-09 19:54:18 UTC
(In reply to comment #5)
> It's ironic that people are bashing this idea as 'unwiki':
> In order to submit a bug to bugzilla, you have to create an account, 
> which sends your password to the e-mail address you specify.

That is not in the *slightest* ironic: bugzilla is not a wiki, and probably *is*
rather "unwiki". Plus, although rather annoying, the e-mail verification here is
used not to "prove" identity per se, but to ensure that all bug
reporters/commenters are reachable by e-mail, so that things can be clarified if
necessary. I've seen people use disposable addresses to report bugs here, and
have had to close the bugs *because there's no way of discussing them* - except
in the unlikely case that the reporter remembers to check back regularly, even
if no-one has answered them for the first few weeks.

> I'm not sure how that process differs from this proposal...

The process doesn't differ, but the *purpose* does, as explained above. It also
differs because the purpose of the software, and the site, differs - open access
is not a key attribute of bug tracking software, it *is* a key attribute of
wikis (or traditionally has been, anyway).

> I would call this a good idea, but I don't think it prevents bots 
> very effectively, which I think is likely to become a more long-term 
> pressing concern than vandalism.

This is the kind of thing that the "friends of gays..." parody is trying to
highlight - are the users likely to be discouraged by the restriction the same
as those you want to discourage? At best, there will be some false negatives
(e.g. bots with e-mail addresses, or non-lazy vandals) and some false positives
(e.g. honest users who can't be bothered), even if these are greatly outnumbered
by the successful discouragement of casual vandals too lazy to register.

To repeat my earlier statement:
Whether it would *ever* be the right answer, I'm not sure - certainly such a
site would feel a little less like a "real" wiki, but maybe there's room in the
world for such sites...
Comment 7 Derek Atkins 2006-01-26 19:41:30 UTC
For what it's worth, some people are using mediawiki (or wikis in general) as a
means to lower the barrier of entry for information sharing between people who
aren't trusted to make changes to the source code.  E.g., the subversion server
in under tight control and only pre-approved users get access to commit code,
but we want to reduce the wiki-spam we get.  Denying accounts based on email
accounts is much easier than blocking accounts based on IP Addresses.

Sure, there are places that give out free email accounts, but a spammer isn't
going to get 20,000 hotmail accounts just to make wiki-spam.  As it's been
stated before, it's an extra barrier to entry.  In /our/ case it's a barrier
we're willing to live with. If the software had the functionality to support it,
we would certainly turn it on.

I urge you to consider implementing this feature...  Even if it's turned off my
default, people want it.

Thanks.
Comment 8 Tobias McNulty 2006-02-07 04:57:49 UTC
Created attachment 1379 [details]
(optionally) requires e-mail confirmation prior to page editing on new accounts

The crucial problem here is that in its current state, MediaWiki either (a)
leaves account creation open to everyone with no authorization (including spam
bots), or (b) requires some kind of intervention on the part of the
administrator to create new accounts. A solution that requires a user to enter
a valid e-mail address and confirm it before being able to use the account (and
edit wiki pages) is, I think, much needed here.  In short, we need a middle
ground between the two extremes of account creation mechanisms (totally open
and closed except to administrators).  Blocking on an admin for a new account
stunts productivity, but leaving a wiki wide open is not an option for
installations that don't have huge teams to control spam.

The attached patch installs support for requiring e-mail confirmation on new
accounts before they're permitted to edit pages.  It introduces a new group,
'editor', which users are added to after confirming an e-mail address.

To turn it on, set:

$wgRequireEmailConfirmationForEditing = true;

in LocalSettings.php
Comment 9 Tobias McNulty 2006-02-07 05:03:00 UTC
I forgot to mention - this patch is for MediaWiki 1.5.6
Comment 10 Get_It 2006-02-28 15:54:46 UTC
I think that this would be better than the captcha system that is being used.
Yes, it might be more annoying that the captcha, but at least blind people would
be able to pass this "test" more easily.

Best regards,
Comment 11 Derek Atkins 2006-02-28 15:58:15 UTC
FYI, I've been using the patch in comment #8 and it works great on my wiki.  I
just had to manually put all the existing confirmed users into the editors group
in mysql, but beyond that it's been working great.
Comment 12 MiG 2006-06-18 17:34:22 UTC
(In reply to comment #6)

Bug report starter suggests a 'configurable option' - which obviously not
everyone has to enable. 

The reason I'm responding here though is not because of this feature request
(although imo it's quite a useful addition) but to Rowan's reaction:

> Plus, although rather annoying, the e-mail verification here is
> used not to "prove" identity per se, but to ensure that all bug
> reporters/commenters are reachable by e-mail, so that things can be clarified if
> necessary. I've seen people use disposable addresses to report bugs here, and
> have had to close the bugs *because there's no way of discussing them* - except
> in the unlikely case that the reporter remembers to check back regularly, even
> if no-one has answered them for the first few weeks.

Fact of the matter unfortunately is that these pages *are* accessible without
logging in, making them a prime harvesting resource for spammers. I originally
used my actual mail address to register here when I noticed all mail addresses
are in plain sight, after which I quickly replaced it with a disposable mail
address. When this has reached the end of its life in three months I'll replace
it with another one, but I will *not* submit my mail address to a site without
any means of hiding it from the public. I imagine I'm not the only one being
tired of dozens of spam messages per day.

It may be slightly off-topic, but I feel that this had to be mentioned in light
of mr. Collins' response.
Comment 13 Chad H. 2009-10-31 00:39:33 UTC
WORKSFORME. Can prevent editing by non-emailed-confirmed user by setting the following:

$wgAutopromote['emailconfirmed'] = APCOND_EMAILCONFIRMED;
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['emailconfirmed']['edit'] = true;

Also, if requiring confirmation before account creation, there's the ConfirmAccount extension. I don't know if it has a "User has confirmed their e-mail" feature, but that'd be a bug for it, not here.
Comment 14 Alexandre Emsenhuber [IAlex] 2009-10-31 07:32:23 UTC
There's also $wgEmailConfirmToEdit for that (http://www.mediawiki.org/wiki/Manual:$wgEmailConfirmToEdit).

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


Navigation
Links