How do Application Forms work? TAG: Activate

Security Discussion
Knowledge Base 2.0 article 426

How do Application Forms work?

Navigation Path
Custom Forms 

This is a security discussion. 

This article describes the work flow of how data is handled and transferred from a temporary database to the institution's production data.  It also describes WHY we require user authentication for application forms.

Custom Forms can be used to create online application forms.
Any time you create a public facing form that writes data to your database you open yourself up to the risk of malicious activity.  With the OASIS Technologies platform we have taken steps to try to mitigate these types of activities to both protect our servers and to protect your data.

Each prospect must “sign in” to the application form by creating a temporary student account.
While this seemingly may feel like an unnecessary step, we feel that the security of your data is a top priority and we require a small level of user authentication prior to giving the user direct access to your application form (and the ability to write data to the database.)

We restrict each IP address to no more than 6 new account attempts per a 6 hour period.
Often malicious activity will involve some sort of automated process (bot) that will continually hit a website using some sort of pre-programmed algorithm.  With each failed attempt the (bot) learns and then tries again.  Depending on the resources of a (bot) server, a typical (bot) can submit as many as 100-200 attempts per second.  To combat this process we restrict each IP address to no more than 6 new user attempts per each 6 hours.  Our network security gateway is set up to handle problematic sites as necessary.

The prospect is required to authenticate their email address.
The user's email address is a key part of user authentication into the software platform, as such we do require that the user provide a valid email address that they have access to.  In order to validate the users email address we will email them a 4 digit code that they have to repeat back to us.  We realize that users may create “fake” email accounts to by-pass this level of security. 

Once the user authenticates their email address the users data is moved from our temporary server to the school’s production  server (database) where it can be accessed by admissions staff
This step does create the ability for the user to sign into the school's production site.  In order to prevent prospects from having the ability to do this the user account is set to an “un-activated” state.  Un-activated accounts are not allowed into the production site.

The application form website has two links “Apply / Register Now” and “Sign In”
In the event a prospect did not complete their application and they wish to return to the application form they need to select the “apply” or “register now” link rather than the “sign in”.  In the event that they select the wrong link they will attempt to sign into the production server.  The software will give them an “account not activated” error and a button / prompt to return to their application form. (see image above)

An admissions officer must approve the account.
Once an applicant has been approved by the admission staff they can allow the user to sign into the production site by “activating” the users account.  The user CAN NOT access the production site until this step is done.

The prospect can now sign into the student portal.
Once the user's account has been activated the user can sign into the production site and access their account information / additional forms etc.