Use temporary redirect for RFC5785 change password well known resource

Trivial patch of the month? (:

Reviewed merge request !3636 working fine, attaching screenshot for the refernce.

Think this should be fine.

LGTM.

This feels kind of contrived?

When would the password edit form in a Drupal site be anything other than the user edit form?

We're not redirecting using a path, we're redirecting using a named route.

Are we sure this is really an issue in Drupal - other than compliance with the spec?

Thanks everyone for your time. Sorry, hope I'm not making busywork. I saw a Slack discussion on the route recently, it was new to me, I was genuinely surprised it was a 301, checked the spec, and discovered it shouldn't be. (Needless to say, I'm not having any functional issues.)

When would the password edit form in a Drupal site be anything other than the user edit form?

When I posted the patch I was thinking that both the quoted risks might be relevant: a cache-aware user agent requests /.well-known/change-password the first time, but subsequently it assumes the same user is logged-in and requests a specific user's edit form; or if there's a change to the redirect destination for whatever reason (eg. the password's now edited on a different route, or the route now has a different URL), agents with a cached redirect from before the update would also misdirect their users.

Are we sure this is really an issue in Drupal - other than compliance with the spec?

Absolutely not! I thought compliance with the spec would be a good thing, so we don't need to think about the edge cases quite so hard (:

Feel free to close if there's no interest, sorry again if I'm wasting time, it just seemed a quick obvious change we could make, kinda regretting it now!

And thanks again!

No need to be sorry, my job as a committer is to ask hard questions

I hadn't considered that a poorly configured upstream cache may cache the 301, although you'd likely have bigger issues there because caching logged in traffic is going to cause all sorts of grief

But on that basis I think this is a low risk change to make

Restoring status

Committed to 10.1.x and backported to 10.0.x and 9.5.x

Automatically closed - issue fixed for 2 weeks with no activity.