Information Technology

Localization

Whlle aLogin2 was designed as a standalone authentication system for low security situations, there are several situations where you will want to expand or even replace aLogin2 to better suit your particular situation. The two most common would be

  1. You want to make use of another local user database in conjunction with aLogin2.
  2. You want to make use of another local user database instead of aLogin2.  This could be if you're working with a web application that was built using aLogin2 but that doesn't really suit your needs.

The solution to both this situations lies in the localLoginChecks.php file.  This file will be copied into your web application directory by the setup process.   This file contains routines that are called by aLogin2 before doing any authentication checks.  As provided, the routines don't do anything, but you can modify them to do whatever checking you want and then return the values to aLogin2. The routines provided are,

localLoginCheck(username,password,localArray - This function is the heart of the localization system. It not only checks a user at login time, but also whenever they try to update the database. This prevents somebody from hacking the javascript while it runs on their browser and granting themselves increase authority.  It takes a username and password, determines if it passes whatever localized checks there are and returns the results.  The localArray is simply an array of values that is created by the web application and passed to aLogin2 when the aLogin2 object is created.  It would contain whatever additional values your localized function requires.  If not needed it will be empty.

This function returns an array, in this example results, that contain the results of the check.  The array keys and values are,

results['complete'] - true if the local array is handling the authentication completedly.  The rest of aLogin's own checks will be skipped.  If false then aLogin will run it's normal checks.

results['status'] = true if the username and password are acceptable.

results['authority_level'] = numeric value for the authority level for this user.  If the status is false, this field is meaningless and can be omitted.

The provided stub routines returns ['complete'] = false and ['status'] = true.

localNewAccount(username, password, email, authorityLevel, defaultLevel, managerEmail, reason, localArray) - This function is called whenever a new Account should be created.  Most of the parameters are obvious and some may not be needed in a particular situation.  Again, localArray is simply a way of passing values from the web application through aLogin to the local function.

This function returns an array in the same form as for the localLoginCheck. 

The array keys and values are,

results['complete'] - true if the local array is handling the authentication completedly.  The rest of aLogin's own checks will be skipped.  If false then aLogin will run it's normal checks.

results['status'] = true if the username and password are acceptable.

results['authority_level'] = numeric value for the authority level for this user.  If the status is false, this field is meaningless and can be omitted.

The provided stub routines returns ['complete'] = false and ['status'] = true.

updatePassword(username, password,localArray) - This function updates a password.

This function returns an array in the same form as for the localLoginCheck. 

The array keys and values are,

results['complete'] - true if the local array is handling the authentication completedly.  The rest of aLogin's own password changing code will be skipped.  If false then aLogin will run it's normal update.

results['status'] = true if update was completed, false if it failed.

The provided stub routines returns ['complete'] = false and ['status'] = true.

Examples

While the possible variations of this are endless, let's consider some simple situations.

  1. You have another user authentication system, but it doesn't support authority levels and your application needs them.

    The simplest solution for this case would be for the other authentication system to handle all of the real work.  The web application could then use the addUser API to create an account for each user with the correct authentication, or you could create the accounts using the administrative functions.  The checkAuthority API call can then be used to check the authority level of any user.  For simplicity you'd probably use a common password in aLogin2 since the other system is really handling the security.  The classic case of this would be an application hidding behind an .htaccess file. 
  2. You have another, more secure, user authentication system, but it contains users that you don't want to give access to your application.  For example, a college might have a campus authentication server, but you want to limit access to a class.

    In this case you would modify the localLoginCheck function to query the other authenticaton system.  If successful it would return true for ['status'] but false for ['complete'].  This would trigger aLogin to run it's own check against it's database.  The user would have to pass both tests to accepted.  You can pass information about the other authentication system, such as the username/password to use on it, through the localArray.

    Alternatively, you could force the users to pass the other authentication system before they get to your page.  Then they would login again using the aLogin system.  This would also get them authority level.  To make this administratively simpler, you may be want to set up a group account that is shared by people with access.  This would be especially useful if the site had some useful features that were generally available but others that are restricted such as a page where anybody in the larger authentication system can read but only a small group can modify.

    Unfortunately, since the passwords should be different on both systems, this will require collecting both passwords.  However, we simply do not have enough confidence in this system to recommend sharing passwords between aLogin and more secure system.  Fortunately, in some situation you may not need the other password.  If the other authentication system supports the concepts of "groups" it may be sufficient for you code to see if the username is in the correct group.
  3. You want to give access based on that person being either in the aLogin datebase or in another authentication system.

    We currently don't support this function.  If the localLoginCheck fails, the request for authority from aLogin will fail.

  4. I have an application that came with aLogin, but I don't want to use it.

    Depending on what the application is doing, this may or may not be a problem.  If the application is only using aLogin for basic authentication features, you may be able to modify localLoginCheck to use another system and return ['complete'] as true, skipping the rest of aLogin.  Alternatively, if your authentication system works better outside of the application, such as a .htaccess approach, you can modify localLoginCheck so that both ['complete'] and ['status'] always return true.  In other cases it may be possible to handle the authentication outside of the application and simply ignore an login features that came with it.  Unfortunately, the best answer to this situation depends the details of the application.
  5. You have another authentication system and don't need authority levels.

    Then why are you using aLogin?

We are still working out the possible situations.  When we have real examples we will add them to this pase. If you run into issues or problems, please let us know.