Проблема - восстановление пароля покупателя

[RGB]

Сегодня заметил непонятное мне поведение ОС в сабжевой ситуации. Суть в следующем - беру чистую версию 1.5.4.1 (сначала обнаружил это на своей сильно измененной и подумал на свои кривые руки), регистрируюсь как покупатель, выхожу из аккаунта и жму восстановление пароля. Ввожу мыло и вижу ушедшее письмо с новым паролем на локалке.

Теперь ключевой момент - если его открыть через разные почтовые клиенты, то увидим такую картинку:

 

 

С виду все ок, но если попытаться ввести этот восстановленный пароль и залогиниться, ничего не выйдет. Сначала я полез в phpmyadmin и сравнил хеши измененного пароля (ид покупателя 3) и такого же пароля, который я вручную указываю в админке для нового пользователя (4), и какого же было мое удивление, когда у этих паролей все оказалось разным!

 

 

Тогда я полез в исходники письма, и удивился второй раз за вечер - в исходниках-то пароль длиннее на один символ!

------=_NextPart_bcd3e43fd42e2b764a750d36c87f0cad
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Новый пароль был запрошен от Мой Магазин.

Ваш новый пароль:

8d6d93a681
------=_NextPart_bcd3e43fd42e2b764a750d36c87f0cad--

 

Оказывается, некоторые почтовые клиенты (из того, что я пробовал и что смогло открыть письмо в виде eml-файла, это оказался Outlook, Live mail, Kernel eml viewer) по каким то причинам обрезают последний символ в пароле, в итоге письмо зрительно выглядит корректно, но пароль таким письмом восстановить никогда не удастся, только если не полезть в исходники. Кто что думает?

 

На почту (гмейл по крайней мере) все приходит как надо, но я очень часто вижу людей, которые до сих пор пользуются The Bat или аутлуком..

[rb2]

Попробуй при отправке письма "\n" в конце добавить.

Ну или какие там символы используются (\r\n может быть? не заглядывал в исходники).

Или в eml вручную добавить и посмотреть заново.

[RGB]

Увы, если в исходники добавить перевод каретки и перенос строки именно в виде \n или \r (через enter все срабатывает) после

------=_NextPart_bcd3e43fd42e2b764a750d36c87f0cad--

то последний символ пароля все равно не отображается (а если до, то они интерпретируются как обычные символы, и последний обрезается). С тем же успехом можно просто после пароля добавить любую строчку с любыми символами и пробелом в конце, пробел обрежется и все будет как надо.

 

К слову, при регистрации покупателя тоже приходит обрезанное письмо (в конце почтовый клиент показывает Мой магази)

После регистрации на сайте Вы сможете воспользоваться дополнительными возможностями: просмотр истории заказов, печать счета, изменение информации Вашей учетной записи и др.

Спасибо,
Мой магазин
------=_NextPart_2196ecb50e86bad692ea2154cf96dadc--
 

А при оформлении заказа все нормально, при этом если открыть исходник письма, то там между NextPart и телом письма есть перенос строки

  <p style="margin-top: 0px; margin-bottom: 20px;">Если у Вас есть какие-либо вопросы, ответьте на это сообщение.</p>
</div>
</body>
</html>

------=_NextPart_0c6623681a2f2c5191f265e9c7094837_alt--
------=_NextPart_0c6623681a2f2c5191f265e9c7094837--

 

Похоже, что дело в этом, хотя я все равно не очень понимаю почему так получается, но не могли же на opencart.com этого не заметить, значит вероятнее всего проблема касается только локализованной версии

 

PS Соответственно, решение проблемы для корректного восстановления пароля такое - в файле \catalog\controller\account\forgotten.php

строку 

$message .= $password;

заменить на

$message .= $password . "\n\n";

[rb2]

Увы, если в исходники добавить перевод каретки и перенос строки именно в виде \n или \r (через enter все срабатывает) после

------=_NextPart_bcd3e43fd42e2b764a750d36c87f0cad--

Не после, а перед. В конце текста письма.

Похоже, что дело в этом, хотя я все равно не очень понимаю почему так получается, но не могли же на opencart.com этого не заметить, значит вероятнее всего проблема касается только локализованной версии

Могли. Они там и не такое не замечают.

 

заменить на

$message .= $password . "\n\n";

Ну вот, я об этом и говорил. В конце текста письма добавить пустую строку.

Кто в глюке виноват - почтовые клиенты или неточное следование стандартам на оформление писем, я не подскажу. Если есть желание - надо читать соответствующие RFC и стандарты на формат этих "многотомных" писем.

Проблема ещё может быть и в неправильных концах строк. То есть, допустим, по стандарту или по "так повелось" ожидается, что там используется "\r\n" или просто "\r" или "\n", а письмо формируется с помощью другой комбинации. И в месте этого подвопросного места и конца секции - возникает глюк. Может оно заметно только на виндовс и на этих клиентах, а на юниксах и линуксах по-другому работает.

[ergil]

Пол дня ищу на форуме тему (видел ее в прошлый раз), к которой было описано почему не приходят письма об восстановления пороля от личного кабинета покупателя. Может кто-то подскажет?