Admin reset of customers password

[mshultise]

When the Admin changes a users password, an email is sent out which includes the new password in the clear. Is there a switch to disable that email being sent?

If not I see where I can delete it from the code from customers.php. I just have to update it each version.

[lat9]

When the Admin changes a users password, an email is sent out which includes the new password in the clear. Is there a switch to disable that email being sent?

If not I see where I can delete it from the code from customers.php. I just have to update it each version.

There's no switch or notification that can be of aid.

To remove that code from customers.php, I'll suggest commenting it out, as highlighted below.

    case 'pwdresetconfirm':
      if ((int)$customers_id > 0 && isset($_POST['newpassword']) && $_POST['newpassword'] != '' && isset($_POST['newpasswordConfirm']) && $_POST['newpasswordConfirm'] != '') {
        $password_new = zen_db_prepare_input($_POST['newpassword']);
        $password_confirmation = zen_db_prepare_input($_POST['newpasswordConfirm']);
        $error = FALSE;
        if (strlen($password_new) < ENTRY_PASSWORD_MIN_LENGTH) {
          $error = true;
          $messageStack->add_session(ERROR_PWD_TOO_SHORT . '(' . ENTRY_PASSWORD_MIN_LENGTH . ')', 'error');
        } elseif ($password_new != $password_confirmation) {
          $error = true;
          $messageStack->add_session(ERROR_PASSWORDS_NOT_MATCHING, 'error');
        }
        if ($error == FALSE) {
          $sql = "SELECT customers_email_address, customers_firstname, customers_lastname
                  FROM " . TABLE_CUSTOMERS . "
                  WHERE customers_id = :customersID";
          $sql = $db->bindVars($sql, ':customersID', $customers_id, 'integer');
          $custinfo = $db->Execute($sql);
          if ($custinfo->RecordCount() == 0) {
            die('ERROR: customer ID not specified. This error should never happen.');
          }

          $sql = "UPDATE " . TABLE_CUSTOMERS . "
                  SET customers_password = :password
                  WHERE customers_id = :customersID";
          $sql = $db->bindVars($sql, ':customersID', $customers_id, 'integer');
          $sql = $db->bindVars($sql, ':password', zen_encrypt_password($password_new), 'string');
          $db->Execute($sql);
          $sql = "UPDATE " . TABLE_CUSTOMERS_INFO . "
                  SET customers_info_date_account_last_modified = now()
                  WHERE customers_info_id = :customersID";
          $sql = $db->bindVars($sql, ':customersID', $customers_id, 'integer');
          $db->Execute($sql);

//-bof-20210713: Don't send password-change emails
/*
          $message = EMAIL_CUSTOMER_PWD_CHANGE_MESSAGE . "\n\n" . $password_new . "\n\n\n";
          $html_msg['EMAIL_MESSAGE_HTML'] = nl2br($message);
          zen_mail($custinfo->fields['customers_firstname'] . ' ' . $custinfo->fields['customers_lastname'], $custinfo->fields['customers_email_address'], EMAIL_CUSTOMER_PWD_CHANGE_SUBJECT, $message, STORE_NAME, EMAIL_FROM, $html_msg, 'default');
          $userList = zen_get_users($_SESSION['admin_id']);
          $userDetails = $userList[0];
          $adminUser = $userDetails['id'] . '-' . $userDetails['name'] . ' ' . zen_get_ip_address();
          $message = sprintf(EMAIL_CUSTOMER_PWD_CHANGE_MESSAGE_FOR_ADMIN, $custinfo->fields['customers_firstname'] . ' ' . $custinfo->fields['customers_lastname'] . ' ' . $custinfo->fields['customers_email_address'], $adminUser) . "\n";
          $html_msg['EMAIL_MESSAGE_HTML'] = nl2br($message);
          zen_mail($userDetails['name'], $userDetails['email'], EMAIL_CUSTOMER_PWD_CHANGE_SUBJECT, $message, STORE_NAME, EMAIL_FROM, $html_msg, 'default');
*/
//-eof-20210713

          $messageStack->add_session(SUCCESS_PASSWORD_UPDATED, 'success');
        }
        zen_redirect(zen_href_link(FILENAME_CUSTOMERS, zen_get_all_get_params(array('cID', 'action')) . 'cID=' . $customers_id));
      }
      break;

[carlwhat]

When the Admin changes a users password, an email is sent out which includes the new password in the clear. Is there a switch to disable that email being sent?

If not I see where I can delete it from the code from customers.php. I just have to update it each version.

another email situation.... ah....

There's no switch or notification that can be of aid.

....

with all due respect, i disagree...

the more i see the need for email manipulation, the more usefulness i see for the framework provided in this plugin:

https://www.zen-cart.com/downloads.php?do=file&id=2315

one could copy the notifier to one's admin/includes/classes/observers directory, and change the 2 methods as so:

    public function __construct()
        {
            $this->attach($this, [
                'NOTIFY_EMAIL_READY_TO_SEND',
            ]);
        }

        public function update(&$class, $eventID, &$p1, &$p2, &$p3, &$p4, &$p5, &$p6, &$p7, &$p8)
        {
            switch ($eventID) {
                case 'NOTIFY_EMAIL_READY_TO_SEND':
                    if ($p2->Subject == EMAIL_CUSTOMER_PWD_CHANGE_SUBJECT) {
                        $p2->clearAddresses();
                    }
                    break;
            }
        } 

when an admin changes a password, the following would appear in the message stack:

ERROR: Failed sending email to: "larrys account" with subject: "Account password reset" You must provide at least one recipient email address.
ERROR: Failed sending email to: "larry" with subject: "Account password reset" You must provide at least one recipient email address.
Password updated.

in addition, a debug log now gets generated.

solving this next part of the problem could involve either creating a blackhole email address at your domain and adding that email to the notifier (the top 2 messages in the message stack would disappear) ie after the clearAddresses():

$p2->addAddress('[email protected]'); 

or alternatively, something that i do is to create a cronjob to remove debug logs that i know about and do not need attention (happens a bit with IH); ie:

#!/bin/bash
grep -li one.recipient.email /var/www/PATH/TO/LOGS/myDEBUG-a* | xargs rm;

a few hoops to jump through, perhaps, but not touching core code has become the holy grail for me.

finally, perhaps the NOTIFY_EMAIL_READY_TO_SEND notifier could incorporate a switch so that an observer could turn it off right there? could be PR time...

best.

[mc12345678]

another email situation.... ah....



with all due respect, i disagree...

the more i see the need for email manipulation, the more usefulness i see for the framework provided in this plugin:

https://www.zen-cart.com/downloads.php?do=file&id=2315

one could copy the notifier to one's admin/includes/classes/observers directory, and change the 2 methods as so:

    public function __construct()
        {
            $this->attach($this, [
                'NOTIFY_EMAIL_READY_TO_SEND',
            ]);
        }

        public function update(&$class, $eventID, &$p1, &$p2, &$p3, &$p4, &$p5, &$p6, &$p7, &$p8)
        {
            switch ($eventID) {
                case 'NOTIFY_EMAIL_READY_TO_SEND':
                    if ($p2->Subject == EMAIL_CUSTOMER_PWD_CHANGE_SUBJECT) {
                        $p2->clearAddresses();
                    }
                    break;
            }
        } 

when an admin changes a password, the following would appear in the message stack:

ERROR: Failed sending email to: "larrys account" with subject: "Account password reset" You must provide at least one recipient email address.
ERROR: Failed sending email to: "larry" with subject: "Account password reset" You must provide at least one recipient email address.
Password updated.

in addition, a debug log now gets generated.

solving this next part of the problem could involve either creating a blackhole email address at your domain and adding that email to the notifier (the top 2 messages in the message stack would disappear) ie after the clearAddresses():

$p2->addAddress('[email protected]'); 

or alternatively, something that i do is to create a cronjob to remove debug logs that i know about and do not need attention (happens a bit with IH); ie:

#!/bin/bash
grep -li one.recipient.email /var/www/PATH/TO/LOGS/myDEBUG-a* | xargs rm;

a few hoops to jump through, perhaps, but not touching core code has become the holy grail for me.

finally, perhaps the NOTIFY_EMAIL_READY_TO_SEND notifier could incorporate a switch so that an observer could turn it off right there? could be PR time...

best.

"One" step easier, no forcing of a debug log to be generated or an email dump location (recognizing that the mere act of pushing the email out is still a concern of "in the open").

Since this is a ZC 1.5.7 question/issue.

Listen to (observe): $zco_notifier->notify('NOTIFY_EMAIL_ADDRESS_TEST', array(), $to_name, $to_email_address, $email_subject);

public function notify_email_address_test(&$class, $eventID, $emptyArray, &$to_name, &$to_email_address, &$email_subject) {

/*
- reset the internal variable for indicating to skip sending the email
- Perform the test of the $email_subject as above/before.
- Set an internal variable in the observer class to support skipping sending the email.
*/

    if (isset($this->skipEmail)) {
        unset($this->skipEmail);
    }
    if ($email_subject == EMAIL_CUSTOMER_PWD_CHANGE_SUBJECT) {
        $this->skipEmail = true;
    }
}

Then listen to: $zco_notifier->notify('NOTIFY_EMAIL_DETERMINING_EMAIL_FORMAT', $to_email_address, $customers_email_format, $module);

public function notify_email_determining_email_format(&$class, $eventID, $to_email_address, &$customers_email_format, &$module) {

/* 
  - if to skip sending the email then
    change $customers_email_format to 'NONE'.
*/
    if (!empty($this->skipEmail)) {
        $customers_email_format = 'NONE';
    }
}

Unfortunately, I see that the response to that is to completely exit the function (return false) rather than to move to the next record or some other process to allow one of the other multiple email addresses to be processed... But that is a separate issue.

No additional logs generated, email is not sent. That said, though, seems that this goes a little beyond the original request... Here now *no* message is sent to the email address compared to an email being sent that is desired to not have the password included... Of course, that I say that, it *does* look like the request is to not send the email at all instead of to send it without the password included... Lat9s suggestion keeps the email going out, but without the password...

It appears that then the above observer (NOTIFY_EMAIL_READY_TO_SEND) could be used to alter the body/altbody of the message to read what is actually desired instead of the default message... Again, using "triggers" to identify/control the desired action(s).

[carlwhat]

"One" step easier, no forcing of a debug log to be generated or an email dump location (recognizing that the mere act of pushing the email out is still a concern of "in the open").

....

i agree that this method is better...

in general, i am not a fan of these hard coded switches, ie NONE cause the method to exit, but a different topic.

Unfortunately, I see that the response to that is to completely exit the function (return false) rather than to move to the next record or some other process to allow one of the other multiple email addresses to be processed... But that is a separate issue.

i do not see a problem here. the method only processes one email, and there is nothing done with the return value in the customers.php script (at least that i can tell...)

[mc12345678]

i agree that this method is better...

in general, i am not a fan of these hard coded switches, ie NONE cause the method to exit, but a different topic.



i do not see a problem here. the method only processes one email, and there is nothing done with the return value in the customers.php script (at least that i can tell...)

In this portion of the code:

    // loop thru multiple email recipients if more than one listed  --- (esp for the admin's "Extra" emails)...
    foreach(explode(',',$to_address) as $key=>$value) {

The theory is that there may be multiple recipients: $to_email_address is the value for the "current" recipient.

At the point of the evaluation of 'NONE', that then current recipient is being "evaluated". If *THAT* recipient isn't to receive the email, then guess what, no one further is to receive it regardless the number of recipients. That is because of `return true` instead of `continue`...

Sooo... Anyone that is having problems with emails being initiated (e.g. no log of an email when logging emails), it is possible that one or more of the recipients had their setting to 'NONE' or 'OUT' such that any previous recipient would have been "sent" the message, but that one and any further would not...

So yes, it processes one email, but considers multiple recipients and that area of the code neglects consideration of any subsequent recipient if the current one doesn't want to receive emails.

[mshultise]

Thanks for the suggestions. I will look closely at each suggestion.

The neighbor doesn't mind the email actually being sent out, if to stop it requires too much to implement. They scrapped their previous (specially coded store) for Zen-cart because the previous programmer was charging them 'boatloads' of dollars to not send passwords in the clear.

My fallback may be to just modify the file to not send the password. It lets the customer know that the password was changed, and perhaps it also could contain a link for them to reset it.

I don't expect that the Admin will be changing passwords often.