User screen "New Password" web-context behavior?

Support
1

Our client, with access to the manager, wants to use the “Let the user choose their own password via email” option under the “New Password” checkbox on the User screen General Information tab. The users that the client which to reset are their clients - all “web” context only users, and their front end access and log in is managed via Login/Register snippet and a combination of Access Permissions and Resource Groups.

When our client clicks on “Let the user choose their own password via email”, the email is sent ok. It’s when the user clicks on the link in their email to reset their password, they get redirected to the Manager login screen, not the web Login screen.

The users all have appropriate Access Permissions. Is there a way for our client manager to use the “Let the user choose their own password via email” option within the manager, but the user themselves gets redirected from the email to the appropriate web-context Login screen on account of their access permissions and context? Thanks.
Modx 3.2.0

2

I suppose in theory you could change the email message (lexicon string = user_password_email | namespace = core | topic = user) and change the URL in the link to a different value.
But I don’t think the Login extra can handle this use case on the front-end. (The Login extra has a ForgotPassword/ChangePassword functionaliy, but that seems to work differently.) I guess you’d have to implement a custom solution.

3

Thanks Harry. We could do a custom solution. How would you go about hooking into the password email fired from the manager user screen?

4

You can’t really “hook into the password email fired” process. Like I wrote above, you can only change the email message. Then on a custom “set the password” page, you have to replicate the code from the login controller (as described below).

This is what happens when you create a new user with the option “Let the user choose their own password via email”:

  • The code generates a random hash
  • The hash is stored in the DB via the registry → $register->send(...)
    (DB-table modx_register_messages | column id = hash | column payload = script that returns the user-name)
  • An email gets sent with the URL .../manager/?modhash=<some_random_hash> that has a request parameter modhash with the hash value.

See the code here.

When the user clicks the link in the email, this is what happens in the login controller of the manager:

  • Check if there is a GET parameter modhash ($_GET['modhash'])
  • Check if a register entry with this hash exists ($registry->read(...))
  • If both checks are successful, the login_new_password_note is displayed (“Please confirm your new password …”) and two <input> fields with the names specifiedpassword and confirmpassword (and a hidden field modhash for the hash) are added

When the user sends the form with the password fields, the code

  • checks if there is a request parameter modhash
  • checks if a register entry with this hash exists ($registry->read(['poll_limit' => 1, 'remove_read' => false]))
  • checks if a user with this user-name exists ($this->modx->getObject(modUser::class, ...)
  • checks the password (both fields have the same value, password length, …)
  • sets the new password
  • removes the registry message ($registry->read(['poll_limit' => 1, 'remove_read' => true]);)