don't allow use old password when change password
Description
Environment
Attachments
Activity
Hiep Lq April 18, 2015 at 2:51 AM
i re-check IDEMPIERE-2558-PR-repatch.patch.
seem i make a wrong patch. it's safe for ignore it.
Carlos Ruiz April 17, 2015 at 9:52 PM
Thanks - I was not able to integrate the PR-repatch - but I was able to integrate the incremental patches - please check if something was missing there.
I added one additional commit as the SQL syntax in core is mandatory to be oracle, we cannot add specific postgresql SQL in core.
Hiep Lq April 9, 2015 at 1:37 AM
because your patch is diff file. i can't merged it by TortoiseHg, must use eclipse. because i re-patch it.
i also add new patch fix your comment
2 - the classes X_ must not be changed manually - on next release all the X_ classes are regenerated and your comment about deprecation is lost
=> fix by total remove column DictWordLength
3 - In MPasswordHistory.getPasswordHistoryForCheck - the usage of sysconfig USER_LOCKING_MAX_PASSWORD_AGE_DAY is not related - locking is a different feature than history
=> fix by use only Days_Reuse_Password
4 - The table ad_password_history requires the columns created, createdby, updated, updatedby, isactive (I know they are not necessary for the usage you're giving actually, but is better to preserve the consistency of all tables - in case somebody wants to show such table in a report or window)
=> fix by add column to table
Carlos Ruiz April 8, 2015 at 4:16 PM
Thanks , tests on this went fine but I have some concerns to solve:
1 - attaching a patch with minor fixes IDEMPIERE-2558_PR.patch
2 - the classes X_ must not be changed manually - on next release all the X_ classes are regenerated and your comment about deprecation is lost
3 - In MPasswordHistory.getPasswordHistoryForCheck - the usage of sysconfig USER_LOCKING_MAX_PASSWORD_AGE_DAY is not related - locking is a different feature than history
4 - The table ad_password_history requires the columns created, createdby, updated, updatedby, isactive (I know they are not necessary for the usage you're giving actually, but is better to preserve the consistency of all tables - in case somebody wants to show such table in a report or window)
Regards,
Carlos Ruiz
Hiep Lq April 7, 2015 at 3:36 AM
what's in my patch?
1. IDEMPIERE-2558-updateLib.patch
update library, because new dictionary don't has DictWordLength, just deprecate function getDictWordLength and hidden field DictWordLength in password rule window
2. IDEMPIERE-2558-passwordHistory.patch
+ add table passwordHistory, each time user change password, it save new pass to history (this table is a object for housekeeper)
+ add column Days_Reuse_Password to password rule. because can configuration it per rule.
+ when change password
+ query all password history of login user has age < Days_Reuse_Password + USER_LOCKING_MAX_PASSWORD_AGE_DAY
+ in new password in list result, don't allow change
Details
Details
Assignee
Reporter
Hiep LqLabels
Affects versions
Priority
Minor
at moment, when password expiate user must change password.
configuration CHANGE_PASSWORD_MUST_DIFFER don't allow user reuse old password
but after change password, user can reset password to old.
my idea change logic become DON"T_ALLOW_OLD_PASSWORD_FOR_PERIOD_OF_TIME
and admin can define num of day.
user can't reuse old password has age in this range.
example: define DON"T_ALLOW_OLD_PASSWORD_FOR_PERIOD_OF_TIME = 30
user can't reset to password has age < 30 day + expiate
other i thinks this configuration and USER_LOCKING_MAX_PASSWORD_AGE_DAY should move to Password Rules
wdyt?