Reconciling password.reset.flow.submit and password.change

[stuartpb]

As #4 describes, there should be a field describing where you go after a password reset form is submitted (which is independent of password.reset.token.login).

Maybe password.reset.submit , which could have a 'redirect' (with 'yes' or the status code used for redirection, or 'no' if it actually doesn't redirect on submission), as well as a 'location' (the URL you are redirected to). And/or something that describes if you're redirected to the login page, and if that login form has some fields pre-filled.

[stuartpb]

There's also the matter of password.change.sessions.invalidate, which is similar. (Should it be documented where you go after changing a password? I feel this isn't that important and it's usually the user dashboard.)

[stuartpb]

This is being addressed, somewhat, by password.reset.steps (#70). URLs still aren't recorded (except when it's the ordinary login page).

[stuartpb]

This is now (post-#127) part of password.reset.flow.submit.destination. Though not everything mentioned here is currently addressed (ie. which login fields are pre-filled), there's room for all of it as sibling/child fields.

[stuartpb]

I've tweaked the issue to focus on pursuing that aspect of this, how to make password.change more resemble password.reset.flow.submit (and maybe vice versa).

I thought about having password.reset.flow.submit look more like password.change (ie. calling it password.reset.flow.change and moving password.reset.usability onto it), but I decided against it, under the thinking that it needs to be clear that the parts of that like session and destination and all are triggered when the password change is submitted: however, that could maybe be addressed by making it password.reset.flow.change.submit (and moving usability to password.reset.flow.change), which would then complement password.change.submit neatly.

This is also less awkward of a construction now that there's no expiration(.trigger) to match with the field name.

[stuartpb]

This is a really sensible change, honestly - the only part that sticks out a bit for me is a kind of dumb one: making it so the two can easily be expressed non-redundantly, as expressed at #120 (comment).

Really, I'm leaning to the side of just "eh, it's not worth getting worked up over" and moving forward with this proposal: some kind of unifying change can be introduced later, and there's no reason to make the fear-of-maybe-not-being-as-perfect-as-possible be the enemy of the good here.

[stuartpb]

Well, in v0.1.0 there's password.reset.flow.change and password.reset.flow.submit, so I'd say this was resolved with #171 closing #163 and introducing a password.reset.flow.change.form that mirrors password.change.form.