Password reset
The reset-link request
Laravel's password broker refuses two kinds of request, and Fortify passes both refusals on:
| Request | Fortify on its own |
|---|---|
| an address without an account | "We can't find a user with that email address." |
| an address that asked for a link a moment ago | "Please wait before retrying." |
Only an address with an account can have asked a moment ago, so both refusals say that the account
exists. The package answers each of them with the response your application gives for a link that
was sent, with Laravel's "We have emailed your password reset link." On a web form that is a
redirect back with the message flashed as status, and for a JSON request it is the same body with
200 OK. If you bound your own SuccessfulPasswordResetLinkRequestResponse, that is the one the
refusals receive.
The broker still mails only an address that has an account, and only once within its throttle. A malformed address is still refused by Fortify's validation, which depends on the input alone.
The reset
Fortify's reset fails with "We can't find a user with that email address." for an unknown address
and with "This password reset token is invalid." for a known address whose token is wrong or has
expired. The package answers every failed reset with the second one: on a web form a redirect back
with the error on the email field, and for a JSON request a 422 with the same error. A reset
with the right token goes through as before.
Switching one off
Each of the two has its own switch, in case your application answers it in a way of its own:
FORTIFY_HARDENING_PASSWORD_RESET_LINK=false
FORTIFY_HARDENING_PASSWORD_RESET=false
The difference in time on these routes is covered in Timing.