Release 0.0.2

This version builds upon the earlier version and introduces two database tables (passwordcontrol and passwordcontrol_meta). The first table is the main table and contains details of when the user last changed their password and the hashed version of the current password. The second table contains details of the plug-in version.

When the user first connects to the system an entry is made in the passwordcontrol table. When the password is changed the table is updated by the onUserAfterSave event. Part of the checks involved includes verifying whether the user has actually changed their password. The new password is hashed using the same salt as the original password and compared. If they are the same then the passwordcontrol table is NOT updated, thus the user would be prompted again to change their password.

Two routines onUserBeforeSave and onUserAfterSave have been looked at. Ideally we wanted to use onUserBeforeSave but this did not (at the time) have the passwords in the clear to enable them to be checked. Routine onUserAfterSave had them visible but of course at this stage the details have already been saved in the database (in the #__users table). This means that even if the password is changed to itself we can still force them to change it again.

All newly registered users created after the plug-in is enabled will automatically be subject to the specifications of the parameters as specified. Any pre-existing users will not by default be forced to change their passwords unless the check box is ticked to indicate that they must be subject to the same rules.

It is recognised that there may be some users for whom it is desired that they are not forced to change their passwords. These users are catered for by specifying their user identifiers in the ‘exempt users’ box. Multiple user identifiers are specified by separating the ids by a space or a comma, which ever is preferred. [Since replaced by a select list.]

There is a specific check for when a user changes their password before they are prompted. In this situation the next change date is adjusted so that it is the specified number of days into the future, assuming of course that the periodic change feature is configured.

Go To Top

Joomla! Debug Console

Session

Profile Information

Memory Usage

Database Queries