I'm not familiar with this exact framework, so this is generic security advice, but: The correct way to handle password reset flows (with a token contained in a URL that the user is emailed, and then clicks), is for the token itself to be used to look up the user. You don't need any other way to identify the user (the token is unique for every user, and indeed for every password reset attempt, of course).
It is a very bad idea to even have some other way to identify the user who is resetting their password, because if you do that, you open yourself to the risk of an attacker entering somebody else's email address (or user ID, or name, or whatever) and resetting the other person's password instead. To prevent that, you would need to confirm that the token from the link is the current password reset token for the indicated user, and if you can do that, you can identify the user from the token directly and there's no need for the user to supply the identity. Passing the identity in the URL is not any safer; an attacker can modify the URL before loading the web page just as well as they can lie about their identity in a web form.
If there's no way for the server to look up a user from their password reset token, then frankly that is an incredibly silly bug and should be reported and/or patched (if open source) immediately. A bug like that would make me seriously question the quality of the entire authentication codebase.
EDIT
The possibility that the requirement exists to provide additional security occurred to me, but I didn't include it in the answer initially as it seemed unlikely. It should be completely impossible to brute-force the tokens; they should be minimum 128 bits of securely-generated random string, with a lifetime measured in minutes (single-digit hours at most) before use and expiring immediately upon use. That leaves only ways for an attacker to capture the token before it is used, and there are mitigations to all of those vectors:
- Attacker captured the victim's URLs (perhaps in a proxy log or similar) and manages to use the token to reset the victim's password before the victim can do it themselves. The odds of this ever happening in a situation where the attacker couldn't also determine the victim's email address is pretty minimal (as it implies that the attacker is able to view the plain text of the victim's HTTPS traffic).
- Victim clicks the link then walks away from their computer before completing the password reset, without locking it, and the attacker sits down in front of the machine. This both involves a level of "user is being incredibly foolish" (and you know what they say about making something idiot-proof), and the attacker could just go look up the victim's email address (they're sitting at the computer where the victim just clicked the link!) in the event that the attacker didn't already know it. This attack is more properly mitigated by making the password reset page itself have only a very short lifetime (it should not take more than five minutes to enter a new password, max, even assuming the user is disabled and must use a really slow input system).
There is an argument for, in extremely paranoid situations, protecting against the first case by accepting the cost of user hassle and taking the risk of insecure implementation. For the most part, it seems like a clear net negative in utility. The second case doesn't even really bear mentioning because the "protection" of requiring the identity is trivially bypassed. Unless there's some other scenario I'm missing, this provides negligible benefit.
