3 ms·

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 i

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.

richardwhiuk 10y ago
Redirect to a page setting a cookie with the token in, which is then scoped to the domain via Site Origin policies.
kijin 10y ago
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 10y ago
  >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.