Extension Documentation

Event onAfterRoute
Prev Chapter 6. Logic Flows Next

Event onAfterRoute

  1. Check whether within the administration back end or debugging and if so return

  2. If guest user return

  3. Get plug-in parameters

  4. Determine whether the user is specified in the user exemption list, or is a member of any specified exemption groups.

  5. Check whether we have this particular users change details. If not we need to add them to our database table. The settings used will depend on the specified parameters.

    1. If the user is exempt just add them to the table with the change date as null.

    2. If we are forcing first time password changes set the last password change to the register date.

    3. If we have a one off change date and it is greater than the current date, set the next change date to that date.

    4. If we are only forcing changes every so many days set the next change date based upon the current date.

    5. Otherwise the change date is left null.

    If the user is exempt, either by virtue of being specified in the user exemption list or because they are members of an exemption group we do not need to go any further and can return.

    If the user exists in our table we now check whether a single one off password change has been requested by the system administrator. Depending upon the actual date specified in the plugin parameter 'once_date' the parameter will be handled as follows:

    1. If no single change date is specified return to calling point.

    2. If once_date is more than the ‘change days’ setting in the future, the routine just returns until such time as the change date comes into range, at which time it is processed.

    3. If the once_date is in the past, the next password_change will be forced whenever the user next logs in or if already logged in when they navigate to a new page.

    4. If once_date is between the current date and ‘change days’ in the future, if sets the change date to that specified.

    In cases iii and iv above after changing the last_password_change and next_password_change in the #__passwordcontrol table, the code then will reset the plugin parameter back to null.

  6. If we are not forcing a password change return.

  7. If we are forcing the initial password change and our last visit date is null the user has never visited before.

    1. If the user is saving their profile we just update our last visit time and update the next password change time to now.

    2. If the user is editing their profile ensure the next change date is set to current date. Set the session variable to make the password change mandatory.

    3. If the option to force an email address change is set then set the session variable to be picked up by the form setup.

    4. Otherwise redirect to the edit profile form.

  8. The user has logged in before

  9. Check if a password change is required

  10. If last change date is null set it to the account registration date.

  11. If we have a one off change date greater than the current date set the next change date to the one off date.

  12. If the next change date is not set update it to the current date.

  13. If we are performing regular password changes

    1. If the user is saving their profile do nothing.

    2. If they have saved their profile and we have requested redirection, redirect the user.

    3. If they are editing their profile

      1. If next change is null return

      2. If the last change is greater than the next change date update the next change date.

      3. If the next change date is in the future return

      4. Otherwise redirect the user if requested.

At this point we are changing the passwords periodically and the next change date should never be null. However on a fresh installation of the plug-in the pre-existing users will have a null value for the next change date. It would also be NULL if the system administration had tried setting initial password change before setting periodic password changes because then users would have already been created on the system.

  1. If the next change date is set to null return

  2. Check if we have the situation where the user has optionally changed their password early without us prompting. What we do here is just update the next change time as appropriate.

  3. Determine if the current date is lower than the next change date.

    1. If the next_change date is not within our specified time to give an early change prompt return.

    2. In it is then prompt the user to change their password.

      1. If they accept direct them to the change screen

      2. Otherwise set the session variable so they are not prompted again this session.

  4. If the user has exceeded our criteria and is to be blocked, block the user in the database and inform them to contact the site administrator. There is a specific check to ensure that the user is not an administrator co that they are not blocked. In addition there is a check to ensure that if the change date is the registration date they are not blocked either. This allows for the situation where the user was previously blocked and the registration date was set to the last change date and it would obviously be a lot older than our change criteria. Clear the user’s session and then redirect them to the front page.

  5. From here on we now know we have to change the password

    1. If the user is saving their profile do nothing but we will update the last visit date to current.

    2. If they have saved their profile and we have requested redirection, redirect the user.

    3. If they are editing their profile

      1. If next change is null return

      2. If the last change is greater than the next change date update the next change date in the database.

      3. Otherwise ensure password specification is mandatory and redirect the user to change their password.

Prev Up Next
Chapter 6. Logic Flows Home Event onUserAfterSave
Go To Top

Joomla! Debug Console

Session

Profile Information

Memory Usage

Database Queries