How does use invalidate reset tokens?

[stuartpb]

Bountysource appears to invalidate tokens on GET (or, at least, they just invalidated the link I got after I signed out and visited it again without resetting).

(Implicit redflag: This is super bad practice since GET requests should be idempotent.)

I'm thinking this should be tracked as password.reset.token.invalidate, with the value being a string (like password.reset.token.login) that describes when the invalidation happens.

[stuartpb]

Closing in favor of #70.

[stuartpb]

This was later superseded by a refactor suggested in light of discussion on #52, which introduced password.reset.expiration.trigger (which works similarly to the proposed password.reset.token.invalidate here, but with better coherence with the password.reset.steps array introduced with #70).

[stuartpb]

Further lineage: expiration was eventually moved into steps as the expire value as part of the refactor of #127, which was derived from ideas in in #120.

[stuartpb]

Regarding this:

(Implicit redflag: This is super bad practice since GET requests should be idempotent.)

I should probably put this somewhere else, but it's kind of not that bad of a practice, when you consider what the attack scenarios against token reuse are. I mean, yes, GET should be idempotent, but... I think only having the latest session to request the given token be allowed to submit is a sensible compromise. (I think I wrote about this somewhere else in this repo, but you want to subsume the token into session via redirect due to potential Referrer header leakage.)