[Normal_gaussian]

So the fragment solution requires JS, invalidate on request can be upset by email scanning antivirus, manual token entry is inconvenient.

So my first thought is returning a page with no external requests (render on the srrver) which isn't very dev friendly.

My other thought is returning a redirect to a page with a token derived from the original token and the clients IP or some other fingerprinting information.

[kijin]

Redirect is the cleanest solution.

Most frameworks provide some form of storage (whether server-side or client-side) that is tied to a specific session, so you can use that to remember the fact that the current session recently used a valid password-reset token for user ID 123.

Or you could use a similar mechanism to put the token in a hidden <input> after redirection, so that it gets submitted again when the user types in their new password.

[bahjoite]

>Redirect is the cleanest solution.

Exactly. Submitting tokens via GET requests (as is necessary for an emailed token) should be handled in the same way as POST (POST-redirect-GET): the resource which validates the token should not be the one that presents the "password reset" form.

[richardwhiuk]

Redirect to a page setting a cookie with the token in, which is then scoped to the domain via Site Origin policies.