Implementation

The Internal System

Login: The user was first confronted with a login screen in which they would enter their unique user name and password. When they clicked 'Submit', sessions are created for that user with the session register command. Sessions are stored in the server as opposed to cookies, which are stored on the user's computer. The password that the user entered was converted to md5, which is a hash function that is used for encryption. This was to ensure that someone who manages to view the passwords in the database would not be able to use them in the login form. Validation was performed by checking if the user name and password occurred together.

If the username and password entered by the user did not match, the user was directed back to the login form. It was believed that it would be more secure not to give error messages to inform the user whether it was their username or password that was incorrect, so as to not help potential intruders guess the password if they have a valid username.

Logout: When the user had finished using the system, they could logout. This would call the function sessiondestroy() which destroys all the data associated with the current session by deleting the session file on the server.

Update the Website: The majority of the internal system contained forms to update the website. As discussed earlier, the staff at ABC knew basic HTML and would therefore be comfortable using HTML to update the text. The pages therefore consisted of large text boxes where the staff could enter HTML. These text boxes contained the data for the corresponding field in the 'text' table so the staff could edit the existing HTML. On 'Submit', an update query would be called to update that data to the 'text' table.

Update the Offers: The deals section on the main page required a different form of input, as each deal had a description, price and url. As there were many offers for a single title (e.g. holidays would have several offers), it would not be appropriate to display all deals for every title at once. A drop down menu was therefore implemented which would automatically display the titles from the database. When a title was selected, the text boxes would automatically appear below containing the deals that corresponded to that title. This was achieved by posting the form to retrieve the titles to itself, thus acquiring the name of the title that was selected. A second query would then be implemented which would retrieve the relevant information and display it in text boxes formatted in rows.

The Feedback Form: The feedback received from the customers could be viewed by anyone logged into the internal system by retrieving all records from the 'feedback' table in the database. It was displayed as a table, listing the customer's name, email and comments. The administrator could clear the table if so desired. This would delete all fields from the 'feedback' table.

Different Access Levels

As the internal system was used to update an ecommerce website, there was a necessity for high security. As discussed in the design, the system had to be protected from potential members of staff who could cause damage by misusing the administrative powers of the system either accidentally or deliberately. It was therefore required to implement two levels of users: administration and normal users.

An extra field in the 'login' table consisted of a single character (1 or 0), which identified whether the user was an administrator or not. A query would be executed to retrieve this value corresponding to the user logged in to the system, which was retrieved from that user-session. If the administration field was 0, the user could update the website, change their account details and logout. If the administration field was 1, a number of additional links appeared in the system, namely, to add users, remove users, view all users and their administrative status and clear the feedback table.