[HOME PAGE] [STORES] [CLASSICISTRANIERI.COM] [FOTO] [YOUTUBE CHANNEL]

Bug 7031 – Don't report that a new password was emailed if no email address was set

Last modified: 2006-08-17 07:29:56 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 7031 - Don't report that a new password was emailed if no email address was set


Summary:	Don't report that a new password was emailed if no email address was set

Status:	RESOLVED FIXED

Product:	MediaWiki
Classification:	Unclassified
Component:	User login and signup (Other open bugs)
Version:	unspecified
Hardware:	All All

Importance:	Normal minor with 2 votes (vote)
Target Milestone:	---
Assigned To:	Nobody - You can work on this!

URL:
Whiteboard:
Keywords:	patch, patch-need-review

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2006-08-16 17:29 UTC by Raimond Spekking
Modified:	2006-08-17 07:29 UTC (History)
CC List:	0 users

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

Attachments
Proposed patch (444 bytes, patch) 2006-08-16 21:42 UTC, Aryeh Gregor (not reading bugmail, please e-mail directly)	Details
Add an attachment (proposed patch, testcase, etc.)

Description Raimond Spekking 2006-08-16 17:29:37 UTC

If an user requests at [[Special:Userlogin]] a new password, the system responds
always with [[MediaWiki:Passwordsent]] ("A new password has been sent to the
e-mail address registered for "$1". Please log in again after you receive it.")
as well a no password is stored in user preferences.

This is very illogical and user complains then via email (ask the OTRS support
teams) that no new password comes.

And believe me... most users don't know if they have entered an email adress at
time of account creating or later.

Solution: Create a new message like "Sorry, for this account no email is stored,
we cannot send you a new password" and check at time of requesting a new password.

Comment 1 Daniel Kinzler 2006-08-16 18:02:34 UTC

this would give anons a way to determine if a mail address is stored for a given
user. Not sure how much of a risk that would be though.

Comment 2 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-08-16 19:26:28 UTC

It's already possible to guess based on what the response is to
Special:Emailuser.  Of course, they could have always disabled e-mail from other
users, which isn't a possibility here, but the additional information that would
be given for this isn't sufficient to justify the confusion this aims to fix.

Comment 3 Daniel Kinzler 2006-08-16 19:47:31 UTC

Anons can't use Special:Emailuser. But I also don't see how exposing this info
would be a lot of trouble. I'd like to get some more input on that though - the
current "confusing" behavior feels intentional.

Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-08-16 19:49:53 UTC

Anyone who signs up can use Special:Emailuser (provided they give a valid e-mail
address, and why not, it's secret).  It should at least say "if that user has
entered a valid e-mail address".

Comment 5 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-08-16 21:42:49 UTC

Created attachment 2235 [details]
Proposed patch

It *looks* like brion broke this in r8618.  He changed
SpecialUserlogin::mailPasswordInternal to return WikiError on failure, but it
continued to return a string if there was no e-mail provided.  Therefore, the
else statement failed to do its job correctly.

Since WikiError.php starts with "Since PHP4 doesn't have exceptions", I'm
guessing it's probably deprecated in favor of MWException, but on inspection it
appears that multiple functions that could be called from all sorts of places
would have to be modified and retested, so I've just had it return a WikiError.
 Tested and works correctly on my install.

Comment 6 Brion Vibber 2006-08-17 07:29:56 UTC

Applied on r16101

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

Search

Personal tools

Navigation

Links

Contents Listing Alphabetical by Author:

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Unknown Other

Contents Listing Alphabetical by Title:

# A B C D E F G H I J K L M N O P Q R S T U V W Y Z Other

Medical Encyclopedia

Browse by first letter of topic:

A-Ag	Ah-Ap	Aq-Az	B-Bk	Bl-Bz	C-Cg	Ch-Co
Cp-Cz	D-Di	Dj-Dz	E-Ep	Eq-Ez	F	G
H-Hf	Hg-Hz	I-In	Io-Iz	J	K	L-Ln
Lo-Lz	M-Mf	Mg-Mz	N	O	P-Pl	Pm-Pz
Q	R	S-Sh	Si-Sp	Sq-Sz	T-Tn	To-Tz
U	V	W	X	Y	Z	0-9