Last modified: 2005-10-10 08:16:00 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 T2677, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 677 - Require email address verification upon account creation (if an email address was given)
Require email address verification upon account creation (if an email address...
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
All All
: Normal normal with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on: 2553
Blocks: 1002
  Show dependency treegraph
Reported: 2004-10-10 20:35 UTC by Jens Ropers
Modified: 2005-10-10 08:16 UTC (History)
2 users (show)

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


Description Jens Ropers 2004-10-10 20:35:25 UTC
Feature request:

I suggest changing our signup process so that any email 
addresses submitted will be verified in a way similar to Mailman's 
opt-in process. (Users not giving an email address obviously 
should remain unaffected.) This verification procedure should 
also be triggered/required if/when users submit an email address 
later and with any change to the email address. 

 It's only a minor inconvenience to users signing up and it's 
probably best practice to do it.
Comment 1 lɛʁi לערי ריינהארט 2004-10-10 21:12:15 UTC
Dear friends, e-mails returned with failure because of the header 
item "Return-path: <>" should be processed in 
the "system" too. This should disable the "email tis user" function 
and prompt to these users during login to go trough the e-mail 
verification again. If a feedback could be given to the sender it 
would be great.
Regards Reinhardt
Comment 2 T. Gries 2005-06-27 19:26:49 UTC
I think, the blocker can be justified after a recent discussion with Brion about
a certain scenario with temp.passwords mailed to not-yet-authenticated address.

Disclaimer, because I am not fully sure, if the scenario can be exploited to
hijack an account:
In case that I was over-reacting, pls. apologize and silently remove the blocker.
Comment 3 Rowan Collins [IMSoP] 2005-08-06 01:06:38 UTC
I don't see any way you could hijack an account using the temp password
mechanism - you'd have to already have control of the account to set the
password, authenticated or not. But I wasn't party to this discussion, so I
won't touch anything here.
Comment 4 Rob Church 2005-10-09 17:01:23 UTC
We already have this functionality; it's a configuration issue.
Comment 5 Brion Vibber 2005-10-10 07:32:31 UTC
Been there for some time. Resolving FIXED.
Comment 6 Kyle 2005-10-10 08:07:40 UTC
Please mention where?  Becuase I sure in the heck don't see anything for it
Comment 7 Rob Church 2005-10-10 08:10:57 UTC
It's configured during MediaWiki installation, in the email options section.
Comment 8 T. Gries 2005-10-10 08:16:00 UTC
(In reply to comment #7)
> It's configured during MediaWiki installation, in the email options section.

see also switch $wgEmailAuthentication and documentation (see )

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