[MGNLPUR-71] Password reminder sends the password encoded Created: 23/Aug/12  Updated: 31/Jul/13  Resolved: 06/Mar/13

Status: Closed
Project: Magnolia Public User Registration
Component/s: None
Affects Version/s: 1.4.1
Fix Version/s: 1.4.3

Type: Bug Priority: Critical
Reporter: Antti Hietala Assignee: Milan Divilek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
duplicate
is duplicated by MGNLPUR-72 The mailed password is encoded, which... Closed
relation
is related to MGNLSTK-1127 integrate MailChangePasswordLinkStrat... Closed
is related to MGNLSTK-1217 integrate MailChangePasswordLinkStrat... Closed
is related to MGNLPUR-69 Provide a way to change password with... Closed
is related to MGNLPUR-89 Allow configuration for multiple sites Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Release notes required:
Yes
Date of First Response:

 Description   

The password reminder email contains an encoded password. It is unusable because the user cannot log in with it. This recovery strategy should send the password in plain text.



 Comments   
Comment by Jan Haderka [ 23/Aug/12 ]

There is no password. We keep only hash so there is no way to clear it out. All we can do is reset the password to something random and send this over. Or send link valid only for certain period of time that allows user to set new password.

Comment by Magnolia International [ 27/Feb/13 ]

The module already has capabilities to generate new password, confirm reset via email, etc etc. This was somehow forgotten/broken when integrating with stk, but it is there.

There used to be a configuration item where you could chose a password recovery strategy, so hopefully you can still use that and reconfigure things properly.

Comment by Magnolia International [ 01/Mar/13 ]

While changing the default recovery strategy is definitely a good move, I would suggest we keep MailCurrentPasswordRetrievalStrategy - or at least mark it as deprecated for now ? I don't think any relevant password mechanism should be able to send clear text password, but perhaps it can serve as an example, showing other behaviours could be adapted.
Or, on second thought, perhaps move the configuration stuff into an abstract class ("MailBasedAbstractStrategy or something), so that MailChangePasswordLinkStrategy is more "focused" ?

Now, we ask users to configure a targetPage - I'm assuming that means very specific components will need to be present in that page. Is this documented ?

Comment by Antti Hietala [ 04/Mar/13 ]

we ask users to configure a targetPage - I'm assuming that means very specific components will need to be present in that page. Is this documented ?

Creating the page and adding a specific component to it is documented in Configuring a password retrieval strategy. Perhaps worth another review.

Comment by Daniel Lipp [ 06/Mar/13 ]

Abstract types should always start with "Abstract" - so MailBasedAbstractPasswordStrategy should be named AbstractMailBasedPasswordStrategy.

Generated at Mon Feb 12 06:42:48 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.