This must have been flagged before…
I have an issue with the password reset form validating to the end user whether or not an email address exists in our system, as this a potential breach of data regulations (especially here in Europe).
I would much rather send the user to a page that says “IF your email exists in our db, we’ll email you”, regardless of whether it does or does not exist.
I did try to workaround this in the User Messages template by adding conditional IF statements to redirect when that message appears, but conditions don’t work in these system templates :(
So in ExpressionEngine, the message should be vague:
'forgotten_email_sent' => 'If this email address is associated with an account, instructions for resetting your password have just been emailed to you.',
Are you using the native password reset or the User or other add-on to perform password resets? Or any chance you’re using a separate language pack, because those could be different from what’s shipped. Or a very old version of EE?
Running EE 7.4.11 so up-to-date. Not using User, just native EE member management. Not using any special language packs that I know of; everything is in default English (not even sure how to change that?)
The email is also in a valid format; I’ve tried using my own personal email address as an example, which I know isn’t registered.
When would I actually see the message you have shown above? That code implies that there is only ever one return, but I set the return as a parameter to a custom page.
Hrm, weird. Let’s see if I can replicate- what’s your url look like on the page where you enter the email? Don’t need the domain, but I’m trying to figure out if you’re using the older member templates or a tag in a regular template. They should both work the same, but I’ll go do some testing.
That specific ‘email doesn’t exist’ message is in the core language files, but it shouldn’t be in use by the password reset, and I can’t find in the code where it is. But… definitely worth digging into.
I’m using a custom template for both, not the preinstalled templates:
{exp:member:forgot_password_form
form_class="cp-form"
return="account/forgot-password/sent"
password_reset_url="account/reset-password"
}
If you can't remember your password, please enter your email address below to set a new one:
<div class="black">
<input type="text" id="login_username" name="username" value="" maxlength="32" size="25" placeholder="Email" />
</div>
<div class="clear"></div>
<button class="btn submit bg-darkblue white" type="submit" name="submit">Submit</button>
{/exp:member:forgot_password_form}
This is how I’ve always implemented this and the login form, as it makes the most sense.
Both otherwise work fine in this configuration; the login form returns a helpfully holistic response of:
The existing username and/or password you submitted are not valid
when an invalid email or password is entered.
Ah- I see what’s going on. So- see this bit:
<input type=”text” id=”login_username” name=”username” value=”” maxlength=”32” size=”25” placeholder=”Email” />
It’s a bit mixed up- for the forgotten password form, you need to be sending an email- that’s saying the field is a username. And that’s why it’s getting rejected.
In the code- a valid email is required. The error that’s triggered posting this is due to there being NO email at all. After that, it’ll check if it’s valid- in the sense that it fits the pattern of an email, not that it’s actually the email of a member.
Try using something more like the example in the docs:
<input type="email" name="email" value="" maxlength="120" size="40" />
Ah noted! Thanks, that works. Interestingly, it works for ‘usernames’ (for which, usernames are emails in this case) that did exist, which is why I didn’t spot the error.
So the follow-up question then: what is the purpose of the return
parameter?
If I don’t set it, and the email exists, the page returns to the same page that the form is on.
If I do set it, and the email exists, of course, it goes to the return page.
If I do set it, and the email doesn’t exist, it goes to the user message template.
In other words, the original problem still stands.
It’s wise to ensure your password reset process doesn’t expose whether an email exists to protect user privacy. Redirecting users with a generic message is a good approach. For a break from coding, try Pokerogue and Pokerogue Dex—they’re great for unwinding!
Packet Tide owns and develops ExpressionEngine. © Packet Tide, All Rights Reserved.