The password reset logic confirms whether en email exists in the user database. This is generally considered bad practice as it enables malicious users to “query” discourse user db. DigitalOcean is a good example of being vague about the provided email, “if the email you specified exists in our system, we’ve sent a password reset link to it”
If you want this, enable it in site settings. Already exists.
By default we tell people since they can never remember which of their 10 email addresses they signed up with, so it is user hostile to force them to walk through all 10 emails to figure out which one they used on your site.
The signup form already gives away if an email address already exists (and turning that off doesn’t make sense) so it doesn’t really matter here, it doesn’t make that attack vector go away and it only makes things harder for users who actually forgot their password (or: forgot their email address)
@codinghorror thanks I didn’t know there’s a setting for it
@michaeld yes, it is true that the sign up form confirms for the existence of an email but one can reduce the email visibility by integrating Discourse with external identity providers or creating a custom sign up form with CAPTCHA.
There are already rate limits on these forms, try it yourself.
我猜这可能是一篇旧帖子，但万一其他人遇到此问题并担心有人可以钓取现有社区成员的电子邮件，看起来 Discourse 实施了一个简单的修复方法。在设置中搜索“隐藏电子邮件地址已存在”并启用它。这将阻止用户使用“忘记密码”来查询您服务器中的电子邮件。
为了将此链接起来，它已在此提交中添加，作为此主题的一部分 - Hide 'email account exists' for invites \n\n\nSign in to GitHub · GitHub) 这是为了将该设置进一步扩展到包括邀请屏幕。不过，这是一个有趣的新增功能，我很高兴我提到了它。
Closed in favour of Email enumeration vulnerability on "Password Reset" dialogue
