Resident Portal Username Recovery/ Password Reset

Resident Portal Username Recovery/ Password Reset

Intent: This document should only be used for defining the process and programatic approach used to implent the password reset process for known users.  This article aims to outline the business logic decisions that were made, why, and how they were implemented.

 

Background: The Password Reset Process only applies to Communities with a Centrally Hosted Resident Portal.  This is due to how backups are ran for remote communities.  The ability for users to reset thier own password aleviates a pain on the communties need to do it for them. This process does require a  user to have a registered email address with fullcount.

 

Usage:  When a Central customer navigates to the login page, there should be two additional links available. One to reset their password, and one to recover their username.

  • Username Recovery: A user can request a username reminder if they have an email address registered with fullcount. This determination is made based on the resident portal (community) instance they are attempting from. They will simply need to enter their email address, with one of three results
    1. No Residents Found : We display a message that says we sent an email, if they don't receive it after 10 minutes they should contact thier community support. We do not actually send a message; this was done for several reason, one of which being to preserve email quota and errantly sent emails (off by 1 errors).
    2. 1(One) Resident Found: We will send an email to the provided email address with the username for that email address.
    3. Multiple Residents Found: We will send an email, but within the email we will say that multiple accounts were found, and indicate they should contact their community for further instructions.
  • Password Reset: A user can request a reset password link; similar to above there are three possible outcomes:
    1. No Residents Found : same as above
    2. 1(One) Resident Found: We will send an email to the provided email address with a password reset link for that user.
      1. We will populate the following fields for the resident:
        • password_reset_expiry - populate this with systime + 2 hours. After the 2 hours has passed this token will no longer be valid.
        • password_reset_token  - populate this with a unique generated token
      2. The password reset link included in the reset email points to a valid url with a query parameter like: 'token={password_reset_token}'
    3. Multiple Residents Found: same as above

Complete Reset Process: There is a ../resetPassword.htm endpoint available. The only requirement is that a token (valid or not) is included in the query parameter.

When navigating to resetPassword.htm we don't do any checks on tokens or expiry. However, when a password is submitted we do check for the existence of both the 'token' matching a password_reset_token, and on the same row, that the password_reset_expiry is greater than current time (meaning it is not more than 2 hours old).

  1. If a row is not found, we display an 'invalid or expired token' exception.
  2. If a row is found we can identify the resident that is requesting the change.
    • We encrypt and update the password for that Resident and delete the token.
    • We leave the expiry value as evidence of the process, and to identify the date in which the password was changed.
  3. The user must now use the updated password on any subsequent logins.

 



    • Related Articles

    • Resident Portal Email Registration Process

      Intent: This document should only be used for defining the process and programatic approach used to implent an email registration process for known users. This article aims to outline the business logic decisions that were made, why, and how they ...
    • New Resident Portal Setup & Communication

      The creation of our new Resident Portal is to be completed by the Implementer/Support representative assigned to the task. This process no longer requres an additional task or scheduled deliverables from our development team. Below are the steps ...
    • API Connect - Resident Portal Implementation

      Assumptions: 3rd party vendor has been validated. Implementation steps: Signed contract/agreement from the mutual customer(s). Contract/agreement provides license and permission to share customer data with the 3rd party. Identify and populate 3rd ...
    • API Connect - Resident Portal Customer FAQ

      API Connect - Resident Portal Customer FAQ What is API Connect - Resident Portal? API Connect - Resident Portal is FullCount's read-only API suite for sharing real-time meal and charge account balances and transactions. The data included is identical ...
    • API Connect - Resident Portal Employee FAQ

      What is API Connect - Resident Portal? API Connect - Resident Portal is a gateway for 3rd party vendor partners to access FullCount's resident information displayed on Resident Portal Our partners will be able to pull resident account balances and ...