Last modified: 2010-05-15 15:37:24 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.
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
> 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.
(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...
After reconsidering the posting and the comments I suggest to close this bug as "WONTFIX".
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.
(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...
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.
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
I forgot to mention - this patch is for MediaWiki 1.5.6
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,
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.
(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.
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.
There's also $wgEmailConfirmToEdit for that (http://www.mediawiki.org/wiki/Manual:$wgEmailConfirmToEdit).
