Allow to change password through RPC endpoints through the reset password workflow

Sounds like a sensible feature request :)

Left a comment at #2403307-295: RPC endpoints for user authentication: log in, check login status, log out to people who were on the original issue aware of this follow-up.

This patch has some security issues.

Same thing as https://www.drupal.org/project/drupal/issues/1521996

Here is the first draft, no tests. I am reusing the /user/password endpoint, if the HTTP method is POST, then this implementation assume it is for resetting password, if the HTTP method is PATCH, then it is for changing password.

As previous patch failed , patch for 11.x.

1. +++ b/core/modules/user/src/Controller/UserAuthenticationController.php
   @@ -260,15 +262,52 @@ public function resetPassword(Request $request) {
   +        if (!$account->isAuthenticated()) {
   +          throw new BadRequestHttpException('Authentication is required to change your password.');
   +        }
   

   Once the patch request is a separate route you can make this a route requirement.

2. +++ b/core/modules/user/src/Controller/UserAuthenticationController.php
   @@ -260,15 +262,52 @@ public function resetPassword(Request $request) {
   +        // Set existing password if set in the form state.
   

   No form state here.

3. +++ b/core/modules/user/user.routing.yml
   @@ -132,8 +132,8 @@ user.pass:
    user.pass.http:
      path: '/user/password'
      defaults:
   -    _controller: \Drupal\user\Controller\UserAuthenticationController::resetPassword
   -  methods: [POST]
   +    _controller: \Drupal\user\Controller\UserAuthenticationController::changeOrResetPassword
   +  methods: [POST, PATCH]
      requirements:
        _access: 'TRUE'
        _format: 'json'
   

   Let's add a different route for just patch. And let it have it's own controller. I don;t think we shoudl be renaming resetPassword here. And I think having a separate changePassword method is okay.

   We can refactor the common parts of both methods into private functions on the controller.

The reason I didn't want to use a seperate controller is because the existing resetPassword uses /user/password.

/user/password is generic, if I use a new path like /user/change_password for changing password, then we have two end points for the consumer. One generic, one specific, that's confusing to me. What do you think?

Attached improved the code comment per suggestion 2

Corrected the patch path

Re-queued the patch since it's against 11.x but DrupalCI was running it against 10.1.

Also just want to say I love that this is using HTTP verb semantics to determine the operation to be performed!

I spoke with @alexpott on Slack, and understood that I can keep the same endpoint but defining a new route based on the new HTTP method. So, I agree with his suggestions.

I pushed the change to the issue fork 11.x

Hiding patches as work is in a MR with correct branch.

But appears to have some failures.

The lastest version is functioning. It supports two use cases:

- Change password knowing the existing password
- Change password without knowing the existing password, but have the timestamp and token from forget password URL

Remaining work to do:

- Tests
- Some of the code are copied from /core/modules/user/src/AccountForm.php and /opt/drupal/web/core/modules/user/src/Controller/UserController.php , better to re-organize them, but need suggestions, as I am not familiar with core.

Passed tests, just needs it's own coverage as mentioned.