Contact Chase

Project Details

  • Employer: GigaShock, LLC
  • Client: Skip Evict
  • Date: 2011
  • Type: Private Web Application
  • Teammates: None

Project Tags

The following tags have been assigned:

Media Gallery

The login page for the application. Users are required to authenticate using two factors of authentication including a username and password combined with a one-time password generated by a hardware token.The administrative control panel allowing administrators of the system to manage authorized users, properties, tenants, user comments, and security logs.The form used to create new users who are authorized to search for and enter new incidents into the database.An example of an administrator's view of a user's profile.
An example of an administrator's view of a user's profile with editing capabilities enabled. In addition to the various fields within the user's profile, the user's password can also be changed using the form in the right column.An example of a modal dialog used when editing individual aspects of a user's profile.An example of the interactive JavaScript password requirements advisor used to enforce policies and ensure that user passwords are highly secure. A server-side implementation of this is also done in PHP to ensure client-side validation is not bypassed.An example of a user's profile where their account has been disabled and their security token has been revoked. Note the ability to re-associate a token using the form in the right column.
A list of authorized users of the system, the properties they are assigned to, and any relevant tags associated with each user.The form used to create a new property.A list of several properties currently in the system, their addresses, and an indication if they are currently active in the system.An administrative tool allowing for a centralized view of all comment threads associated with different elements. Traditionally, this would not be the method used to access the individual comment threads.
An extensive logging system which records all errors, warnings, messages, failed login attempts, and even benign events such as successful page loads. Filters in the right hand column can restrict the results to specific users, IP addresses, or logging levels.A more detailed view of an individual log entry. The "more data" section allows the admin to show even more additional information including SESSION data, POST data, GET data, and other information available in communication headers.The form used when users log tenants SKIP incidents into the database. A similar form is used for EVICT incidents.Allows the user to choose if they wish to perform a search using a social security number or using a last name and date of birth combination.
Form used to search for tenants using a known social security number.Form used to search for tenants using a combination of a known last name and date of birth.Search results matching search criteria.A list of incidents and user comments associated with an individual tenant. This page also give detailed information about a tenant.
A page containing details and comments relating to an individual incident. Users can use the tools on the sidebar to add comments or add payments against the debt owed relating to this incident.A modal window used during the process of adding a payment against the outstanding debt associated with the incident.

Skip Evict

This project was done as part of my work as owner and lead developer with GigaShock, LLC. Skip Evict is a web application I developed for a client to meet a very specific need that they had discovered as their acquisition of real estate communities expanded. Their company had recently acquired, developed, or rebranded a large number of apartment and condominium complexes throughout a small geographic area surrounding, in this case, Phoenix, Arizona.

An unavoidable byproduct of owning such a large number of rental apartments is the need to evict certain tenants from their current place of residence for a variety of reasons. Similarly, a certain number of tenants will also "skip out" and leave their apartments without notice and without fully paying their rent through the end of their stay or through the full term of their rental agreement, leaving the rental company short that amount of rent and unable to contact the prior occupant.

As this company had made many acquisitions within a fairly small geographic area it was, therefore, not uncommon for the individuals who skipped out or were evicted to, sooner or later, fill out a rental application, get approved, move into, and repeat a similar set of circumstances with another of the communities under the same umbrella as the original community they had left, incurring an additional financial loss. This problem is clearly something that can be avoided by sharing information. Unfortunately, there are some issues that complicate this. First, each property has a dedicated rental office that handles the management of that property and had no other need for interaction with the other rental offices at the other properties. For this reason, it was impractical to have each office report to each other office when one of their residence skipped or was evicted and this impracticality would increase as the number of properties in that area increased. Additionally, since the names, social security numbers, dates of birth, and other private personal information about tenants was being shared, there were legitimate security concerns about this type of information being shared in an uncontrolled manner between offices.

Therefore, my solution was a highly secure private web application that managed and controlled the processes of tracking these skip or eviction incidents through to their resolution and placed safeguards and limitations on the searchability of the data. After the application was fully developed, the process looked a bit like this:

  1. After a tenant skipped or was evicted, the authorized representative (usually a manager) for the rental office at the property where this occurred would log into the web application.
    • The process of logging in was secured using several methods. First, all interactions with the entire web application are protected communications over an encrypted SSL/TLS connection. Additionally, to gain access to the system the user is required to use a two-factor authentication system including the use of a unique username, password, and one-time-password generated by a YubiKey hardware security token issued to them individually.
  2. After getting logged in, the user would have the option to input incidents of type "Skip" or "Evict" at which time they would document personal information about the tenant in question, information about the property and unit they were living in (such as the unit number and the amount of money owed), and make any other necessary comments associated with the incident to be made visible to other users of the system.
    • Users entering information into the system are limited to entering incidents relating to tenants in the property to which they are assigned.
  3. Then, at any point in the future, any user of the system can perform a search to see if an individual had been previously associated with an incident at any of the partner properties. This usually occurs during the review of the new rental application. The reviewer will login and perform a search by either a social security number or a combination of last name and date of birth.
    • Search results are only returned on exact matches of fully provided information. As a result, the users performing the search need to know the entire SSN or entire last name and DOB in advance before being shown personal information about a tenant.
    • All activities, including searches, performed by users are logged. This, in addition to conservative daily search thresholds for each user, prevents malicious use of the search tool to reveal private personal information.
  4. If a result is returned for such a search the user becomes authorized to see the information regardless of the property where the incident occurred. They will be presented with the details of the incident including, most importantly, the outstanding balance left to be paid. This user can then make a decision about if they will deny or conditionally approve the new rental application based on the information they have found. In the case where the application is conditionally approved, the tenant must pay the balance of the incident in full before being allowed to proceed with the process. This payment is then documented in the incident database and the status of the original incident is changed to reflect that there is no balance due and the incident has been settled. They can also, if they wish, add comments to the tenant's record that will be visible in results of future searches.