exports = async function({ token, tokenId, username, password }) {
const ses = context.services.get('AmazonSES').ses("us-east-2");
const link = `https://.../reset_password?lang=en&token=${token}&tokenId=${tokenId}`;
// send custom email with link using Amazon SES
const result = await ses.SendTemplatedEmail({...});
return { status: 'pending' };
};
I don’t use the password sent by the app (which I literally fill with "password") for security reasons, because I have no way to authenticate the user.
The link to my website points to a JS script that looks like this:
The problem is, I get the following error every single time I try to reset the password: Request failed (POST https://stitch.mongodb.com/api/client/v2.0/app/REALM_ID/auth/providers/local-userpass/reset): invalid token data (status 400)
Though in my case, even when I’m using the above sequence, I have the same issue which lead me to this thread. I’m using the same flow as the one you have.
My question is, why there is a need to send password to the callResetPasswordFunction when what we are doing is only sending a email via this function and actual ‘reseting the password’ is happening by calling resetPassword function. Perhaps, we are doing something wrong?
Basically, I call the script once to send the reset password email, then I copy paste the token and tokenId I receive in the email, switch the commented code in the script, and run it again to reset the password.
It doesn’t work.
This seems like a bug in the NodeJS driver. I’m going to file a bug.
There seems to be a security hole in the ‘realm-web’ SDK with the resetPassword function.
The initial “newPassword” value that you enter in app.emailPasswordAuth.callResetPasswordFunction(email, newPassword) doesn’t matter when you confirm it with app.emailPasswordAuth.resetPassword(token, tokenId, newPassword)
What I really mean is that you can enter any value for password in app.emailPasswordAuth.resetPassword(token, tokenId, newPassword) and the realm-web SDK confirms the password change like the following.
Running that code through the reset password function will actually confirm the password change when it clearly shouldn’t as “123Apple#” is different from “CrazyBug99” (assuming we extracted the right token and tokenId)