`useSendPasswordResetEmail` does not return an error when an unregistered email is used
Rathetsu opened this issue · 3 comments
useSendPasswordResetEmail
hook returns incorrect success status for unregistered emails
Issue Type: Bug
Description:
When using the useSendPasswordResetEmail
hook, I noticed that it does not return an error
when the email provided is not registered. Moreover, it also returns the success
boolean as true
even when the email is not associated with any user account.
Reproduction Steps:
- Use the
useSendPasswordResetEmail
hook in a component. - Provide an unregistered email to the
sendPasswordResetEmail
function. - Observe that
error
remains undefined andsuccess
returns astrue
.
Expected Behavior:
For unregistered emails, success
should be false
and an appropriate error
should be returned indicating that the email is not registered.
Actual Behavior:
The success
is returned as true
and no error is returned, misleading the user.
Code Snippet:
import React, { useState, useEffect } from 'react';
import { toast } from 'react-toastify';
import { useSendPasswordResetEmail } from 'react-firebase-hooks/auth';
import { auth } from '@/firebase/firebase';
type ForgotPasswordProps = {};
const ForgotPassword: React.FC<ForgotPasswordProps> = () => {
const [email, setEmail] = useState('');
const [sendPasswordResetEmail, sending, error] = useSendPasswordResetEmail(auth);
const handleResetPassword = async (e: React.FormEvent<HTMLFormElement>) => {
e.preventDefault();
const success = await sendPasswordResetEmail(email);
console.log('success', success);
// BUG: returns success as true even if email is not associated with an account
if (success) toast.success("If the provided email address is associated with an account, a password reset email will be sent.");
};
useEffect(() => {
if (error) {
console.log(error);
toast.error(error.message);
}
}, [error]);
}
Environment:
- react-firebase-hooks version: "5.1.1"
- React version: 18.2.21
- Browser: Google Chrome
- Additional Libraries/Tools used: typescript, next, recoil
Additional Information:
If it's an intended behavior to not differentiate between registered and unregistered emails (to prevent email enumeration attacks), then the documentation should clearly mention this. Otherwise, this is misleading for developers using the hook.
Please let me know if you need further information or if there's a workaround available.
@chrisbianca, could you have a look whenever you can?
I had the same problem.
@Rathetsu @zhenyuWang that's because the protection mail enumeration is activated, it is active by default in projects started in September 2023 Read about this