Forgot (Reset) Password action on user resource

Features go against 7.x-3.x dev and are back ported to 6.x

@jjesus there is no such functionality implemented yet. I think we can create additional action reset to reset password for the user. I believe this action should have email as argument.

Would you like to create it?

In order to do that you need to extend user resource definition to add new action and implement callback that will check the passed email and resets the password. Please take a look how core user module does that. I will gladly review your patch.

Thanks!

I would do this the drupal way, submit an email send the email a url, with a token generated, and then have another endpoint that accepts the token.

Here is a patch that adds a new targeted action enabling Drupal's standard password reset functionality to be triggered for specific users. With this, you can make a POST to http://example.com/api/user/1/password_reset to have a standard password reset email sent out to user 1.

Same thing, without the extra whitespace.

Lets replicate drupal native behavior here. I.e. resetpassword should be action and not targeted action as sometimes users won't know their uid.

Cccess check should be in place. We should not allow to use this actions to anyone but anonymous users.

Also test for this resource should be in place.

@mrfelton will you take care about this issue. I am ready to help.

@ygerasimov, please could you clarify...

> Lets replicate drupal native behavior here. I.e. resetpassword should be action and not targeted action as sometimes users won't know their uid.

Not sure I follow. How would a password reset email be triggered if you don't know which user it's for?

> Access check should be in place. We should not allow to use this actions to anyone but anonymous users.

I don't really follow this logic. Why only anonymous users? My use case is that an external customer service application needs to be able to trigger password reset emails to be ent out. The external application is generally authenticated, since it needs to be able to do all sorts of things with the user account such as updating profile details, block, activate, etc. If the password reset action is only available to anonymous users then this webservice would need to unauthenticate just to send the email. That doesn't make much sense. The webservice would be far more useful if any user could trigger the password reset email.

Updated patch adds an additional resource that allows for resending of the welcome email.Pretty much based on the core patch #5688: Resend welcome message from admin user/edit. I included in this patch for 2 reasons:

1) It's kind of related since its about triggering emails to be sent to users

2) Because I am also using the patch from #10, I was unable to add this functionality without creating a patch conflict/dependency.

You may or may not want to treat this in a separate issue, but here it is for reference anyway.

Better logging messages

And without the wiitespace

#16: 1303400.16-services-user-mails.patch queued for re-testing.

So core password reset is based off name and email the service should use the exact same approach. Also there is no point in the resend welcome email lets keep this issue focused on the password reset.

> Also there is no point in the resend welcome email lets keep this issue focused on the password reset.

I agree that that could be tacked in a separate issue, but to say there is no point in the functionality is going a bit far. It's very useful to be able to resend welcome emails. People may not receive them for any number of reasons, and so it is a useful customer service function to be able to resend these emails.

No point may be a bit strong but it should not be a core services feature in my opinion as core offers no way to resend a welcome email.

+1 marcingy
I agree this should be a core services feature.

any working patch here for D6?

Do not change status please.

This patch is based on comment 16, but adds the ability to use the username instead of the uid as the argument ... When will a user ever know their UID?

ok, I applied the patch (Post #25), I do see the services module now include two new methods under the user.

Can someone help me by showing me how to use the feature ?

I tried:

http://example.com/?q=api_name/user/18/password_reset

and
http://example.com/?q=api_name/user/joe/password_reset

both did not work.

Change the status and testing the patch (Post #25).

Dhammika, did you POST to that url? It should be right.
'REST_PATH/user/USERNAME/password_reset.json' works for me. I also see my patch failed. Maybe I patched it wrong.

Yes, the POST was the reason I got the error. Thank you.

Now I have a new error:

When I POST :
http://example.com/?q=API_path/user/username/resend_welcome_email.json

I get an error:

["Access denied for user anonymous"]

I assume the user "username" would not be required to be logged or else it would defeat the purpose of the resend_welcome_email.

This needs test as well.

Any update for this issue? Need to reset the user password using service module.. Any default option available? Thanks for all your help..

Added another patch into this one as it needs to live under the "targeted_actions" as well, which allows users to cancel the user. This is a reroll of #16 as no where else in the services user_resource.inc do they user the user name when loading users, hence disregarded change in #25.

issue merged into this one is #2105039: Drupal code provides a way for admins to cancel user accounts.

attached is the patch, as mentioned in both issues still missing tests.

Bot

Added two new tests to test the password rest and user cancel resources that have been added unfortunately i have no idea how to test the new mail resource. Hopefully this is sufficient to get this patch submitted.

Thanks you @jucallme nice work.

1. +++ b/tests/functional/ServicesResourceUserTests.test
   @@ -228,6 +228,35 @@ class ServicesResourceUsertests extends ServicesWebtestCase {
   +    $account = $this->drupalCreateUser();
   ...
   +    $account = $this->drupalCreateUser();
   

   Can we add proper permissions to account?

2. +++ b/tests/functional/ServicesResourceUserTests.test
   @@ -228,6 +228,35 @@ class ServicesResourceUsertests extends ServicesWebtestCase {
   +    $response = $this->servicesPost($this->endpoint->path . '/user/' . $account->uid . '/cancel');
   ...
   +    $response = $this->servicesPost($this->endpoint->path . '/user/' . $account->uid . '/password_reset');
   

   We need assertTrue for this.

3. +++ b/tests/services.test
   @@ -502,6 +502,17 @@ class ServicesWebTestCase extends DrupalWebTestCase {
   +          'resend_welcome_email' => array(
   

   We need test for this as well. Maybe simple response test with different registration settings

@jibran Here are the changes.

Bot.

updated patch.

Not sure what was wrong with last patch try again.

Awesome.

Thank you @jucallme for more tests and awesome work. Please create interdiffs it is easier to see new changes. https://drupal.org/node/1488712 http://xjm.drupalgardens.com/blog/interdiffs-how-make-them-and-why-they-...
Overall I think this is complete. RTBC for me.

Really great work! Thank you a lot!

Some nitpicks.

+++ b/resources/user_resource.incundefined
@@ -468,6 +565,64 @@ function _user_resource_logout_1_1() {
+
+  $user_register = variable_get('user_register', 2);
+  switch ($user_register) {
+    case 0:
+      $op = 'register_admin_created';
+      break;
+    case 1:
+      $op = 'register_no_approval_required';
+      break;
+    case 2:
+      $op = 'register_pending_approval';

Please use constants instead of magic numbers. Like USER_REGISTER_VISITORS_ADMINISTRATIVE_APPROVAL

+++ b/resources/user_resource.incundefined
@@ -535,6 +690,12 @@ function _user_resource_access($op = 'view', $args = array()) {
     case 'delete':
       return user_access('administer users');
+    case 'password_reset':
+      return TRUE;
+    case 'resend_welcome_email':
+      return user_access('administer users');
+    case 'cancel':
+      return user_access('administer users');

Lets group cases. i.e.

case 'password_reset':
  return TRUE;
case 'delete':
case 'resend_welcome_email':
case 'cancel':
  return user_access('administer users');

+++ b/tests/functional/ServicesResourceUserTests.testundefined
@@ -229,6 +229,56 @@ class ServicesResourceUsertests extends ServicesWebtestCase {
+   */
+  function testCancelUser() {

Please add a test that user no 1 cannot be canceled. Security team will be happier.

Here we go all fixed up @ygerasimov

sorry forgot status.

Great thanks! Committed.

attribution

#25 worked for me and more logical, because forget password should be for the anonymous user by username or email not the uid.

If anyone wanted to load user by email then replace user_load($uid) to user_load_by_mail($uid); $uid is your email, and you should provide your email like this http://example.com/?q=api_name/user/omar@example.com/password_reset

It seems we should also be following along with the Drupal core's user_pass() form function here.

If so, we should accept an argument "name" with a value that is equal to a user name or e-mail address. It seems this would also be an Action (similar to login and register), instead of a Targetted Action.

Don't get me wrong, I see the benefit for a resource that accepts a user id, and resets a password. But perhaps that should be a separate resource (and it already is). So...

Here's a patch for a new user resource, request_new_password:

It works by doing a POST to, e.g.:

http://www.example.com/?q=rest/user/request_new_password.json

And sending along a name, e.g.:

name=john

or e-mail address:

name=john@example.com

Before writing any tests for this, I just wanted to make sure this is agreed upon by the Services team first. Please consider using this patch, thanks!

Love it, can we get a test and call it done?

Added tests. Interdiff attached.

I fixed a small coding standard issue with a stray tab in the test file.

Fix test because drupalGetMails() doesn't provide immediate feedback of e-mails sent. The response code check and a simple count of e-mails should be sufficient.

Looks great, haven't tested it yet but will soon.