`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
useSendPasswordResetEmailhook in a component. - Provide an unregistered email to the
sendPasswordResetEmailfunction. - Observe that
errorremains undefined andsuccessreturns 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