If a user has located their account (so they know its username and id), but does not know their password (nor have a 1FA authentication method added, like CTAP2), they are unable to acquire the e-mail address of the account by merely appending .json to the relevant profile URI.
Consequently, how are they to request a password reset, considering that the password reset form requires an e-mail address; it does not accept a username?
they can search their various email accounts for the forum domain? how many email addresses do they have? 
If all else fails…
a**********t@*****.com? sometimes that’s enough to help (but also does leak a little info, so they might not)Staff users can see a user’s email address that they registered with. The staff can tell the user what their email is, so that the user can log in.
Email cannot be viewed in the JSON. In fact, it’s quite hidden, even for staff (i.e. behind the ‘Show’ button), and is logged IIRC into staff logs.
Is that possible?
@awesomerobot and @NateDhaliwal, the problem with these approaches is that I recently experienced this at community.openAI.com, because I utilise an e-mail alias service, as many nowadays do. Though, it would be worse if one had merely sub-addressed their e-mail address, which is common practice, as that would be infeasible to remember. [1] Unfortunately, no avenue of contact is provided to the moderators, as is true for many Discourse instances, and another problem.
Had I not been able to discover my e-mail address, I would have been out of luck.
It does accept a username, though.
The first form field prompts for email or username.
The link below the first field works, regardless of whether you supplied the email or the username.
The I forgot my password link also works for either username or email, unless the Admins have enabled the Hide email address taken site setting.
On the OpenAI site, the forgot password form requires an email, but on another site where that setting is disabled, the form allows the entry of the username:
So unless I’m misunderstanding your request, it sounds like we already support what you are requesting.
@southpaw, so the ability to accept a username during password resets is a preference, which they have disabled? I ask because what I observe there is:
If so, perhaps that should be made more clear, with something like:
This Discourse instance has disabled username-based password reset.
Though, I do observe the same here:
I do not understand why the form, that you have submitted a screenshot of, appears to differ from what I observe even here.
I’m certain you would agree that preventing others from finding out your email address must be a top priority of the site. To that end, there is a site setting admins can choose to enable that provides an extra layer of protection by refusing to give people hints if they try to guess an email address by guessing at email addresses until they see confirmation that they found a registered one. One of the side effects of that site setting is that the forgotten-password form will not accept the username entry.
The example I gave is from a site with that specific setting disabled.
The two examples you gave are from sites with that specific setting enabled.
This is why you observe a difference.
I’m curious, how would this additional information, beyond the fact that the form field does not accept a username, have made your journey to recovering your account any easier?
@southpaw, I am surprised that it needs to be, because most websites bypass this problem, by merely not indicating whether a password request was successful. Instead, the user enters an e-mail address or username, and if they see a message arrive, they entered valid credentials.
Because many Discourse instances utilise different versions of Discourse, had I observed, at another site, the ability to conduct a password reset, I likely would have assumed that OpenAI’s instance was operating an older version, without the word “username” appended to the string. Consequently, it would have saved me this escapade.
ah yeah that’s a reasonable case… though I’d imagine an email alias service should keep some record of which aliases have been used where? Apple’s does but I don’t have experience with others to know for sure.
Maybe worth opening a feature request to always allow username for password resets? if others are running into this issue it’s something we could consider having
That’s right. If you want to use a service and continue to use the service, it’s your responsibility to know what email address you used. If you forget, then you have to create a new account. The alternatives are all much worse. Email the admin (who does not publish their email address, so you’ll need to create a new account to contact them), then say “Uh, I created an account with an email address that I don’t know. I can’t prove I own it, since I don’t know what it is.” Or you could ask “I created a username secret123, I forgot what email address I used, can you tell me?”
If you’re paranoid enough to use random email addresses then you’re paranoid enough that you use a password manager that will remember the info for you, otherwise, you’re out of luck.
@pfaffman, I didn’t forget. Rather, OpenAI haphazardly disconnected their SSO integration, silently replacing it with an e-mail address inherited from the user’s OpenAI account, and no password bound by default. As @awesomerobot presumed:
…indeed, it (Addy) does, although, in this case, I merely utilised the one that was still bound to my OpenAI account, in my credential manager.
@pfaffman, unless I misunderstand what might be intended to be solely humourous, I do not appreciate your presumption that this was due to incompetence, nor, especially, that I am paranoid, because of my mere use of e-mail middle-ware.
To elaborate on the latter attribute, I utilise the alias service for e-mail triage, because I work as an Emergency Responder for St John Ambulance, a Coastguard Rescue Officer for HM Coastguard, and am a trustee and committee member for multiple national and local charities (including Crimestoppers Trust and Neighbourhood Watch Network), wherein I frequently liaise with [the Office Of] The Police [And Crime Commissioner] for the county within which I live. Additionally, all of this goes to the same e-mail inbox that all of my FOSS work, my personal communications (like SARs), and my security alerts do. Consequently, being able to separate it for the sake of prioritisation is incredibly important to me.
My previous inboxes, before I utilised an alias service, were overrun with spear-phishing attempts from private and national actors, alike. Since I utilised this, being able to control and analyse who has shared which e-mail address to whom has allowed me to reduce the quantity of that spam to barely 2 % of what it used to be.
Consider that condescension may be a lower form of wit than even sarcasm is.
@awesomerobot, thanks. I’ve filed one:
That does sound like a mess.
It sounds like you have important work, involving other people’s privacy and safely, which gives you many more reasons to be paranoid than do most of us. And I think we all have reason to be paranoid. Most of us, in one old man’s opinion, are far less concerned than I think they should be.
My point was that if you lose control of your email address then you should expect for it to be difficult or impossible to reconnect to whatever was associated with that address. The alternative is that someone could take control of your account, regardless of whether you have control of it.
In other words, the only thing worse than not being able to connect to your lost account is for someone else to be able to, especially if you have important work that involves protecting people’s privacy.
But maybe there is some safe way that you could retrieve your account while avoiding having anyone on the planet be able to do the same. That is a very difficult problem. Perhaps you are suggesting some safe solution that I do not understand.
I did not mean to offend.
This reads as if the admins have changed the setting from its default. However, the setting is enabled by default: Hiding "e-mail taken" on sign-up by default. Therefore, unless admins explicitly disable it, it is enabled.
That’s an excellent point, which also (obviously) means the username entry is disabled by default in the password recovery tool. So now I like the feature request even more, but am allowed to vote only once.
@pfaffman, using an IETF RFC 5233 sub-address, which OnMicrosoft/Outlook and GMail / Google Workspace implement, also induces that problem, should one not have their address recorded.
However, I do, in my credential manager, and my aliaser allows me to search them, too:
