Auth0 Home Blog Docs

Why should we not return an error in the get user script when the user does not exist?

custom-database

#1

In case the user is not found the suggested documentation in the code editor indicates that we should return return callback(null).

This does not work as expected. It returns an empty profile.

http://g.recordit.co/JDIEoDaZIV.gif

This has an impact on the API side as well. When calling webAuth.changePassword, in case no user exists the API returns 200 (success).

Changing the code to:

if (results.length === 0 || results === null) {
            return callback(new Error("No user was found with this email address."));
}

the webAuth.changePassword returns 500 Internal Server Error - which I feel is also not the correct response. It should be 400 or 401 instead.


#2

The expected result for the Get User script when the user does not exist is the one you mentioned and that is documented:

return callback(null);

When using the TRY button with a non-existent user we could indeed be more explicit about the result and instead of showing The profile is: label with no associated data we could instead indicate the user does not exist. However, this would just be an improvement over the user interface for the try script option.

The observed behavior that you mention for the change/reset password situation when correctly using the documented approach to signal non-existing users callback(null) is the expected one. The reason here, is that the change/reset password endpoint is a public endpoint that could be triggered by anyone. If the endpoint disclosed if the user existed anyone could check if your email was registered as an account at the particular service and this would most likely constitute a privacy violation.

Even though the change/reset password endpoint does not disclose if the user exists, the email will only be sent for existing users and I believe you will have a log entry available that would indicate that someone attempted a password change/reset for a user that does not exist.

With this in mind, your custom database must comply to the documented contract and return in the expected way for a user that does not exist. If you need a custom change/reset password logic that needs to know the user exists beforehand then you would need to make that check yourself, for example, through the Management API.


#3