Final Year Project

Next: Testing Up: A Web-Based Sports Centre Previous: Design Contents

Subsections

Implementation

This chapter will describe the actual implementation of the system. Much of this chapter could equally well have been covered in Chapter , however it was decided to use a separate chapter to emphasise the difference between the design decisions made early on, and those made during the development of the system. These are covered in Chapter and in this chapter, respectively.

Payment Method

It was decided that for this project, an online payment system using credit/debit card transactions would be unnecessarily complicated, especially since many activities have very low costs (for example, a squash court costs seventy pence for registered sports members). Instead, a simple credit system was used, where users have an amount of credit associated with their online account, and each booking will reduce this credit by the appropriate amount. This is a similar concept to the printer credit system used on the computer cluster workstations in the University of Leeds; this is a benefit since it means that most users are likely to understand the system.

At present, the only way for a user to add credit to his account is to visit the Sports Centre, and request that a member of reception staff add the desired amount of credit. Although one of the motivations for this project was to remove the requirement to physically visit the Sports Centre when booking, it was felt that visits to add credit were only a minor inconvenience. Furthermore, the booking system will remind a user when they are low on credit, so they can simply add more credit when they go to the Sports Centre for their booked session.

Despite the lack of support for online card payments, this support could very easily be added in the future, simply because of the account credit system used. Any card payments would simply have to increase the user's credit, rather than being integrated into the actual booking procedure and charging for a specific booking.

User Identification

Registration

The system includes an online registration feature, primarily designed for use by members of the public, rather than members of the University. There are two main reasons for this:

A potential future improvement to this project is to integrate it with the central university database. In that case, either user information could either be copied from there to the database used by this system, or the central database would be accessed directly by this system, removing the need for a separate user database. Thus, members of the university would be automatically registered and would no longer need to register online.
It can be assumed that members of the public are not registered sports members, and therefore the online registration feature automatically sets all users who register to be non-members. If a registered sports member used this online registration, they would also have to physically visit the sports centre to have their account ``upgraded'' to sports member status.

Usernames

For members of the university, the username used to access this system is simply the local-part of their email address (the part before the @-sign), for example scs0bcps for a student, or Ben.Smithurst for a member of staff.

members of the public Members of the public are assigned a username consisting of their first name, followed by their last name. If a duplicate occurs using this scheme, the username will have a random number appended. Thus, a username for a member of the public would be something like davidbanks or johnsmith453.

The chance of a member of the public being assigned a username that clashes with a member of the university is very small, and will be ignored for the purposes of this project. This is because email IDs within the university contain either a digit that is not at the end (scs0bcps) or a period (Ben.Smithurst), as discussed earlier. Since a username constructed for a member of the public can never contain a period or a digit, the only chance for collisions is if a university email ID did not contain either a period or a digit. (Even in the very unlikely case that a public user's real name contained such a character, they are removed before constructing the username.)

Passwords

When a user first registers, either online or in person in the Sports Centre, they will be assigned a random password consisting of six digits. Although this is not a particularly secure password, it is likely to be secure enough, given that:

The user will almost certainly change it to a more secure password, that is easier for them to remember (the system could potentially force a user change his password the first time he logs in)
The damage an attacker could do with access to a user's account is severely limited

All passwords are stored in the database encrypted using the standard one-way ENCRYPT() function in MySQL (based upon the standard Unix crypt() function). This increases security of passwords, because even if an attacker gained access to the database, he could not determine any user's password, except by using a brute force attack. Although this is irrelevant in the context of this system, because the attacker can do anything with access to the database, some users may use the same password for many different systems, and such encryption helps the security of those systems.

Login Mechanism & Security

For simplicity, it was decided to use PHP's builtin session support for implementing logins. A session has two parts: a session ID, which in the case of PHP is a 128-bit hexadecimal number, and a set of variables associated with that session. Only the session ID is known by the client, normally using a cookie, though it can be passed in the URL by browsers that do not support cookies, or have disabled them.

It is unlikely there are any significantly more secure methods than this, in terms of the design of the site. Using SSL (Secure Sockets Layer) encryption would increase security further, but would not change the design of the site at all. The only way an attacker could gain access to another user's session in this scenario would be to discover their session ID. This could be discovered by any of the following methods:

**Figure:** Dangers of passing a session ID in a URL
$\begin{figure}\begin{center}\epsfig{file=figure/sessid_url.eps} \end{center} \end{figure}$

Guessing - unlikely given that there are $2^{128} = 3.4\times10^{38}$ possible session IDs
Network sniffing - this could quite easily be avoided using SSL encryption, as discussed earlier
Web server logs - when a user follows a link in a web browser, the URL of the referring page (that is, the one containing the link) is sent to the server containing the new page in the HTTP Referer header, which is often stored in the web server log files. Thus, if a user has cookies disabled, so the session ID is stored in the URL (as discussed earlier), this URL will be included in the server's logs. Figure shows this situation. However, the scope for attack here is still fairly small:
- Most users have cookies enabled -- less than 8% either unconditionally refuse cookies, or use a browser that does not support them [#!gvu_cookie_survey!#]
- There are very few external links on the site
- Any external links will almost certainly be to trusted sites within the University
Emailing links - A user may decide to email a link to his friend. Although it is likely he will trust his friend not to do anything to damage his account, this still shows another possibility of a session ID being disclosed.
Looking at a user's screen - A user may walk past a user logged into the system, and see his session ID in the browser's Location bar. The chance of an attacker being able to remember the 32 character session ID is very small however. This case, as well as the previous case, only apply if the user has cookies disabled in his browser.

With sessions, the code to authenticate a user is very simple. The user provides their username and password, and if the username exists in the database, with the specified password, the variable username is stored in the session, and contains the actual username. Also, a variable expires is stored in the session, and contains the time that the current login session expires, expressed as a number of seconds since the Unix epoch ( $1^{st}$ January, 1970). This time is set by default to thirty minutes ahead of the current time, and is automatically updated whenever the user requests a page. This makes it more difficult for an attacker, since he must discover the session ID within thirty minutes of the last time it was used.

To check if a user is logged in, the system must simply check that the username session variable is set, and that the expires session variable is set and is less than or equal to the current time.

Making Bookings

As the most important feature of the site, this was the first major feature to be designed and implemented. A four-stage booking process was used, with the following stages.

Selection of date, time, and activity

This is a similar concept to many other sites which involve bookings, such as thetrainline.com and gobycoach.com. On such sites, the date and approximate time are selected, along with the journey end-points. At the next stage, the exact times for available journeys are displayed. An analogous system will be used here, where the date, approximate time, and activity, are selected at the first stage.

The form elements used to select the booking criteria at this stage deserve some discussion. Initially, a simple dropdown box was used for each criterion, as shown in Figure .

**Figure:** Initial layout of first stage of booking process
$\begin{figure}\begin{center} \scalebox{0.5}{\epsfig{file=figure/newbook1}} \end{center} \end{figure}$

However, this requires at least two mouse clicks and two mouse movements for each criterion, which is not optimal, especially for the Sports Centre reception staff who may make many bookings at once. In the worst case, this would be even more since the user may have to scroll within the dropdown list if the required selection was not immediately visible. To overcome this problem, some simple buttons were included for common selections -- this reduces the actions required per selection to one mouse movement and one click, provided the required selection was included as one of the buttons. This updated layout is shown in Figure . Note that the buttons to select the activity are dynamically generated by using the four most popular activities, and the buttons to select the date are generated as today and the next three days. The buttons for time are always the same, although the ``NOW'' button will always select the current time. Due to the dynamic generation of these buttons, it is likely that they would be used for most bookings, rather than the slower dropdown boxes.

**Figure:** Second layout of first stage of booking process
$\begin{figure}\begin{center} \scalebox{0.5}{\epsfig{file=figure/newbook2}} \end{center} \end{figure}$

**Figure:** Final layout of first stage of booking process
$\begin{figure}\begin{center} \scalebox{0.5}{\epsfig{file=figure/newbook3}} \end{center} \end{figure}$

This layout was slightly confusing -- it is not immediately clear that either the buttons or the dropdown boxes should be used, and some users were unnecessarily using both methods. This problem was solved by hiding the dropdown boxes by default, and only showing them if a button labelled ``more'' is pressed. Another problem was that it was not clear when the buttons had been pressed, as they did not remain visibly ``pressed''. Figure shows the result of fixing both of these issues.

Selection of venues and time slots

The layout for the next stage is quite straightforward, and the first design created is shown in Figure . The user simply ticks the boxes corresponding with the time slots and venues they wish to book. The layout is very simple, with one row per time slot, and one column per venue. The background of the table rows alternate between two slightly different shades of green to make it easier to trace across from the time to a checkbox (or vice-versa).

When the venues for a given activity have differing schedules, as is the case for squash, there are many blank cells, as shown in Figure , meaning the corresponding activity/time slot combination is not valid. Although this could be confusing, it was found to be less confusing than some alternative layouts tried, such as that shown in Figure , which does not make it clear that the two sets of venues have different schedules. (It appears as if two slots on the same row are at the time, which is not the case.) On the positive side, this layout requires less vertical screen space, though it was felt that this minor benefit was outweighed by the potential for confusion described above.

**Figure:** Final layout of second stage of booking process
$\begin{figure}\begin{center} \scalebox{0.5}{\epsfig{file=figure/selslots2}} \end{center} \end{figure}$

Another possible layout (Figure ) attempted to emphasise this difference by having the rows on one side partially overlap with the rows on the other side. This layout helped to a certain extent, but it was still slightly confusing, and some browsers render it no different to the previous layout (Figure ).

Because of these problems, the layout chosen was actually the first one created (Figure ). The layout is simple, but effective.

**Figure:** One alternative layout of second stage of booking process
$\begin{figure}\begin{center} \scalebox{0.5}{\epsfig{file=figure/selslots1}} \end{center} \end{figure}$

**Figure:** Another alternative layout of second stage of booking process
$\begin{figure}\begin{center} \scalebox{0.5}{\epsfig{file=figure/selslots3}} \end{center} \end{figure}$

Summary of booking

Before the bookings are finally confirmed, the user is shown a summary of the sessions they have booked, as shown in Figure . At this stage, the bookings have been inserted into the database, but are not yet confirmed. This means that if the user does not confirm the bookings within five minutes, they will be removed again, making the slots available to another user. This idea of reserving a slot until it is confirmed came from the online booking system used by stercentury.co.uk.

**Figure:** Summary of bookings, prior to final confirmation
$\begin{figure}\begin{center} \scalebox{0.5}{\epsfig{file=figure/booksummary}} \end{center} \end{figure}$

The decision to implement it this way was to avoid race conditions in the booking process. Without such a scheme, the slots may end up being booked by user B while user A was reading the summary page listing the bookings he was about to confirm. This scenario is shown in Figure . If user A wanted to book slots A, B, and C, then he will succeed in booking slots A and C, but it is not unlikely that he would rather not have booked any of the slots, rather than booking a subset of them.

Of course, it is still possible that while user A is selecting slots at stage 2, user B may book those slots, before they become reserved for user A at stage 3. This scenario is shown in Figure . The important difference is that user A will discover this problem before he is charged for any slots (the user is charged between stages 3 and 4). Without this reserving of slots, when user A pressed the ``confirm'' button at stage 3, if user B has booked some but not all of those slots, user A will be charged for those slots that were not booked by user B. If user A was making the booking assuming he was getting all of the requested slots, this may not be desirable. In some cases, user A may not even be able to get a refund for those slots he paid for but no longer wants.

**Figure:** Time line of a booking situation without reservations
$\begin{figure}\begin{center} \epsfig{file=figure/book_time_1} \end{center} \end{figure}$

**Figure:** Time line of a booking situation with reservations
$\begin{figure}\begin{center} \epsfig{file=figure/book_time_2} \end{center} \end{figure}$

This is the stage at which the user will be informed if they do not have enough credit. Alternatively, if the user logged in is a Sports Centre staff member, the page will include a ``top-up'' input box, allowing the user booking in person to have their account credit topped-up at the time of booking. This increases usability of the system by removing the need for the staff to start a new operation to top-up a user's credit while a booking operation is in progress.

Confirmation

This is the final screen shown, and simply confirms to the user which bookings were successfully made, and the corresponding booking_id numbers from the database, as shown in Figure . These ID numbers will then be used by the reception staff to mark bookings as ``attended'' as users turn up, as well as a simple way of checking that users are not using other users slots. (Guessing the ID number correctly for a given date, time, activity, and venue combination is quite unlikely.)

**Figure:** Final confirmation of bookings including ID numbers
$\begin{figure}\begin{center} \scalebox{0.5}{\epsfig{file=figure/bookconfirmed}} \end{center} \end{figure}$

Administrative Features

It is clear that a system such as this one will require some administrative features, because it is being developed for users who are not IT specialists, and will not be comfortable querying the underlying database directly. Such features will range from resetting a user's password, through to adding an entirely new venue or activity to the system.

The administrative features included will be discussed in the following sections.

User Account Management

This is likely to be one of the most frequently used administrative feature on the system -- it is used to perform common operations such as resetting a user's password, or adding credit to a user's account. Because of this, is is important that this feature be easy and intuitive to use.

The design of the search feature is a simple but good example of this. Initially, the search feature would either search by username or by last name, and the user had to manually specify which was required. This was considered too cumbersome, and so it was changed to always search users based on their username, first names, and last name.

Next: Testing Up: A Web-Based Sports Centre Previous: Design Contents