Require password for certain admin actions

Could we consider re-branding this as "Require re-authentication for certain admin actions", to include more authentication setups?

#3 makes a ton of sense to me. That would let sites do TFA codes as well if appropriate.

I forgot this issue existed and opened 📌 Require password confirmation to install new code Active against project browser. Cross-linking the two issues.

Implementation idea: a route option (_reauthenticate: true) which redirects you to a reauthentication page, then forwards you on to the original destination if you pass the authentication.

We'll need this for 📌 Allow composer location to be configured via the UI Active too.

Implementation idea: a route option (_reauthenticate: true) which redirects you to the login page (with your username pre-filled), then forwards you on to the original destination if you pass the authentication.

This is interesting although not sure exactly how it'd work yet.

The way I'd assumed this would happen is that we'd add a confirmation form to every place that needs this, that then also required adding the password (or some other auth method if supported). So you'd submit whichever form 'as normal' but then re-authentication would kick in after that. One issue with this could be consistency - modules would need to implement the confirmation form every time, even if we add a trait etc. to make that easier.

Re-authentication before being able to get to the form at alll would potentially help in cases that information on the form might be sensitive.

If we go for the route option, we'd need a new re-authentication route in system.module that's a password form by default but extensible/replaceable by other auth methods. Don't think it needs the username on it because you already know that if you're logged in.

But also we'll need to store that the user has re-authenticated in a reliable way so they don't end up in an infinite loop. Would putting a timestamp into session be enough? Then we could check the timestamp before the redirect, and that's also an easy way to implement a re-authentication frequency setting without having to use the flood API - just make the recency of the timestamp configurable somewhere.