Last modified: 2006-08-17 07:29:56 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.
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.
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.
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.
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".
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.
Applied on r16101
