Always allow username-based password reset

OpenAI, recently, disconnected their SSO integration; instead, silently replacing it with an e-mail address inherited from the user’s OpenAI account, and no password bound by default. Because I utilise an e-mail alias service for each account, this required that I correctly presume that this had occurred:

This may not be an intuitive process for the average user (not that I’m special, though).

I would prefer to also be able to utilise the account’s id, but that appears to be less popular than usernames, whenever I discuss it. Additionally, it would solely be in addition to this, so it’s probably out-of-scope.

3 לייקים

Just adding for reference that it’s the hide_email_address_taken site setting that, when enabled, (and as noted by @moin, this setting is enabled by default) requires the forgot password form to accept only the full email address. The option to enter a username in that field exists only when the setting is disabled.

I’m having trouble imagining how entering a username there would reveal the existence of a “taken” email address, since we don’t display any part of that email address on the webpage (or anywhere that I saw in the console) after the form has been submitted with a username.

5 לייקים

That’s new. How is it helping? Were people harassing people by sending password resets? It’s quite common for users on old communities not to know what email address they subscribed with.

לייק 1

Wait. What? Why does hiding the email address stop you from being able to reset your password? It used to do this with a message like ‘the email has been sent’, I thought. And the message for using the email address was like “if that email is here, we sent a mage”

Requiring the email address for password reset is a terrible idea. I’m surprised that this hadn’t been seen as a problem sooner.

Oops. Sorry that I sent two replies.

לייק 1

This was an intentional change made here originally: FEATURE: hide_email_address_taken forces use of email in forgot password form - Pull Request #15362 - discourse/discourse - GitHub

This strengthens this site setting which is meant to be used to harden sites
that are experiencing abuse on forgot password routes.

Previously we would only deny letting people know if forgot password worked on not
New change also bans usage of username for forgot password when enabled

So not sure if @sam has any thoughts on walking this back for usernames, at the time of the change it wasn’t the default state, but as of ~2024 it is. I think the risk of allowing usernames is pretty low, someone could potentially use it to send any random user a bunch of emails… but it should be rate limited.