Logins and PermissionsBy Peter McMahon
I was approached to build a financial tracking system for the company I work for during December of 1999. This system would allow the financial people and managers to login, view all the data, and modify it. The employees would be able to login and see what they would be owed for the month (employees are paid on a commission basis). They would only be allowed to see what they were earning, not what anyone else was earning. It was imperative that the data could not be tampered with if someone simply knew the names of the files where the data could be edited, so login state had to be kept. The admin users also needed to be able to add, delete, and modify users.
SSL, or Secure Socket Layers (denoted by URLs that start with
https://) should play a very large
role in the security mechanisms of your site if you are serious about security. SSL allows information to be transferred
securely over the Internet between two parties using a public-key/private-key authentication method to ensure the
identity of both parties (you can read more about how SSL works by reading the articles in the Security Section). If the information that you will be transferring is sensitive (such as financial information), then I strongly recommend that you integrate SSL into your security mechanisms. Most important is the user login form. This is a bare minimum as to what should be protected using SSL, as should someone gain usernames and passwords to the site, you have a very serious security breach.
The first thing I do when I receive a project like this is take out a piece of paper and work out what tables and columns I'm going to need in the database. Following that, I load up MS Access and design my tables. Below is the
Logins table for this project:
Logins table would require a
Username and a
Password column, however I decided on also adding a third column,
Status, which would be used to determine the permissions of any particular user. For example, a user with the status of "Administrator" would be able to view all of the financial documents, whereas a user with the status of "Designer" would only be able to see their financial information.
The first page that needs to be created is the login form. I developed a standard form in an HTML file,
It is important that you use the HTTP POST method to send the login data, not GET, as users would be able to see passwords in the client's browser history, amongst other things that would pose a security threat.
The next file that needs to be created is
login.asp, which will process the login information and set the login state. Here's the basic idea of how the code works:
- Load entries from the database
Loginstable where the
Usernamecolumn is equal to the inputted user name.
- If the returned Recordset is empty (
True), the user name does not exist. Report an error.
- If the returned recordset isn't empty, the user name exists. Check the current record's password against the inputted one.
- If they do not match, the password is incorrect. Report an error.
- If they do match, the password is correct. Set a session variable to store the state of the user.
Here's the code used:
The script is fairly basic and simply opens a database, requests a recordset, checks to see if it's empty or not using the
EOF property (which is true if the recordset is empty), returns errors if appropriate, and redirects the browser if required. The next page that requires attention is
menu.asp that the user is redirected to once they have successfully logged in.
We'll discuss the menu in Part 2!