Online Ticket Booking System: CS39010 Dissertation

Mark Bradley (mdb2) Dissertation CS39030
Online Ticket Sales System
Online Ticket Booking System

CS39010 Dissertation
Author: Mark Bradley

Supervisor: Chris Loftus
Year of Submission: 2006
2
1 Declaration of Originality
This submission is my own work, except where clearly indicated.
I understand that there are severe penalties for plagiarism and other unfair practice, which can
lead to loss of marks or even the withholding of a degree.
I have read the sections on unfair practice in the Students Examinations Handbook and the
relevant sections of the current Student Handbook of the Department of Computer Science.
I understand and agree to abide by the Universitys regulations governing these issues.
Signature:
Name: Mark Bradley
Date:
3
2 Acknowledgements
I would like to thank firstly Chris Loftus my dissertation Supervisor for his continued support
throughout the project.
My family for the emotional and financial support throughout my time at university,
especially my parents who always believed in me and not complaining too much about the
about the 5 hour drive from London!
My long suffering Girlfriend Miranda Williams for her support and late night phone calls
when everything was going wrong and I could not see a solution to a particular problem.
My housemates Claire Procop, Joseph Wardell, Andrew Murray, Julian Chile and Timothy
Knowles who provided relief from work on late nights with social tea breaks and making me
food every once in a while.
I would like to thank Simon Marshall and Gillian Price who have given advice on web
accessibility and allowed me the use of software for accessibility testing and for the loan of
documents regarding accessibility.
Finally a big thanks Janet Roland from the Learning Languages Centre who have read over
this documents too many times to mention.
4
3 Abstract
This document is a report on the progression and problems that occurred throughout the
project and finishes with a conclusion on the outcome of the project.
The project was to create an online ticket booking system, which took into consideration the
many security issues involved with programming for the Internet, securing from the varying
type of attack that hackers can use, including:
SQL injection
Cross Site Scripting
Session Hijacking
The website also the into account accessibility of the website when the layout and structure of
the site was being designed.
The research will include payment solutions available for such a system could use to accept
customer payments.
The project will take the best feature of existing ticket sales website and improve them and
will implement new feature that it is felt will improve customers experience with the site.
This document is accompanied by a CD, containing all the PHP, CSS and include files.
5
4 Contents
1 Declaration of Originality................................................................................................. 3
2 Acknowledgements........................................................................................................... 4
3 Abstract............................................................................................................................. 5
4 Contents ............................................................................................................................ 6
5 Introduction....................................................................................................................... 8
6 Existing Systems............................................................................................................... 9
7 Methodologies ................................................................................................................ 11
8 Project requirements ....................................................................................................... 12
8.1 Use Case Diagrams ................................................................................................ 13
8.2 Functional Requirements ....................................................................................... 14
8.3 Extra Functionality................................................................................................. 15
8.4 Security .................................................................................................................. 15
8.4.1 Structured Query Language (SQL) Injection..................................................... 15
8.4.2 Cross Site Scripting (XSS) ................................................................................ 16
8.4.3 Session Hijacking .............................................................................................. 16
8.4.4 Password Encryption ......................................................................................... 18
8.4.5 Secure Socket Layer (SSL)................................................................................ 18
8.4.6 Allowing only human users ............................................................................... 19
8.4.7 Verifying your users .......................................................................................... 21
8.4.8 Maintaining a secure environment..................................................................... 21
8.4.9 Security Functionality........................................................................................ 21
8.5 Web Accessibility and Usability............................................................................ 23
8.5.1 Web Usability .................................................................................................... 23
8.5.2 Accessibility Law .............................................................................................. 23
8.5.3 Online Testing ................................................................................................... 23
8.5.4 Web Content Accessibility Guidelines 1.0 (WCAG 1.0) .................................. 24
8.5.5 Publicly Available Specification 78: Guide to good Practise in Commissioning
Accessible Websites (PAS 78) ....................................................................................... 24
8.5.6 Conclusion ......................................................................................................... 25
8.6 Online Finance Systems......................................................................................... 26
8.6.1 PayPal and WorldPay ........................................................................................ 26
8.6.2 Credit Card Vendor............................................................................................ 26
8.6.3 Conclusion ......................................................................................................... 26
9 Implementation ............................................................................................................... 27
9.1 Technology ............................................................................................................ 27
9.1.1 Java Enterprise Edition ...................................................................................... 27
9.1.2 ASP.................................................................................................................... 27
9.1.3 PHP Hypertext Pre-processor ............................................................................ 27
9.1.4 Cascading Style Sheets ...................................................................................... 27
9.2 Website Design and layout .................................................................................... 29
9.3 Human Computer Interaction................................................................................. 29
9.4 Site Layout ............................................................................................................. 31
9.4.1 Client Side ......................................................................................................... 31
9.4.2 Administrator Side............................................................................................. 34
9.5 Site Design (Page Layout) ..................................................................................... 36
9.6 Database Design..................................................................................................... 37
9.6.1 Client ................................................................................................................. 37
9.6.2 Card ................................................................................................................... 38
9.6.3 Genre ................................................................................................................. 38
9.6.4 Concert............................................................................................................... 38
9.6.5 Genres................................................................................................................ 39
9.6.6 Band................................................................................................................... 39
6
9.6.7 Venue................................................................................................................. 39
9.6.8 Town.................................................................................................................. 39
9.6.9 Booking ............................................................................................................. 40
9.6.10 Staff ............................................................................................................... 40
9.7 Implementation Process ......................................................................................... 41
9.7.1 Featured Code.................................................................................................... 41
9.8 Problems during Implementation........................................................................... 48
9.8.1 PHP.................................................................................................................... 48
9.8.2 Accessing Objects held as a session variable .................................................... 48
9.8.3 Database............................................................................................................. 48
9.8.4 General............................................................................................................... 49
10 Testing ............................................................................................................................ 54
10.1 Testing PHP applications ....................................................................................... 54
10.2 Test Plan................................................................................................................. 54
10.3 Accessibility Testing.............................................................................................. 54
10.4 User Testing ........................................................................................................... 54
10.4.1 Client Side User Testing................................................................................ 55
10.4.2 Administration Side User Testing ................................................................. 56
10.5 Cross-Browser Compatibility Testing.................................................................... 58
10.6 Testing Outcomes .................................................................................................. 58
11 Critical Review ............................................................................................................... 87
11.1 Methodology .......................................................................................................... 87
11.2 PHP ........................................................................................................................ 87
11.3 CSS ........................................................................................................................ 87
11.4 Security .................................................................................................................. 87
11.5 Accessibility........................................................................................................... 88
11.6 Testing.................................................................................................................... 88
11.7 Improvements ........................................................................................................ 88
11.8 Overall.................................................................................................................... 89
12 Bibliography ................................................................................................................... 90
13 Appendix A Manual Testing Test plan........................................................................ 92
14 Appendix B - results of user testing.............................................................................. 102
15 Appendix C - WAI........................................................................................................ 108
7
5 Introduction
This purpose of the CS39030 (dissertation) project is to produce an online ticket ordering
system. This document reports the design, implementation and testing of the system.
The project will concentrate on ensuring the web site is secure from the varying type of attack
that hackers can use, including:
SQL injection
Cross Site Scripting
Session Hijacking
The website will allows be design with accessibility in mind.
Existing ticket sales websites will researched to ensure that the site has a fighting chance of
competition with them.
The report will look at the look at important parts of code and problems during the project and
how those problems were over come.
The documentation will cover the testing of the project once the implementation stage of the
project is over.
The website produced by this project can be found at:

http://www.digitally-scarred.co.uk/dis/
8
6 Existing Systems
There are currently a number of different websites offering online tickets sales. Some of the
most well known are:
Ticket Master (www.ticketmaster.co.uk), Figure 1.
Aloud (www.aloud.com), Figure 2.
Ticket Web (www.ticketweb.co.uk), Figure 3.
Each site of the site offers a very similar service to their customers. The sites each have a
different way of navigating and searching the site. Ticket master and aloud include links on
their home page to what they describe as hot tickets linking to pages selling latest tickets.
The Ticket Web site home page requires the user to select an area of the county or they must
search for an artist or event there is no mention what tickets they have available.
The search facilities available on each of the sites are similar.
The search on Ticket Master allows users to search by artist, team or venue in a chosen
location.
The Aloud website has a basic search comprising of artist/band or town. The advanced search
allows users to search by artist or event, a set of dates, a venue name and a town.
The ticket web search basic search allows users to search for artists or events. Or browse
events is a select region. The Advanced search allows user to search by region a date and by
key words.
The ticket master website offers accounts to customers so that their details are stored so that
process of purchasing tickets is quicker and customers do not have to fill in forms. Customers
who have accounts receive emails periodically from the site promoting up coming events.
The aloud website offers customers an email list facility where users can enter their email
address to be kept up to date with up coming events.
Figure 1 Screen shot of the Ticket Master website.
9
Figure 2 Screen Shot of the Aloud website.
Figure 3 A screen shot of the Ticket Web website.
10
7 Methodologies
The methodology that will be used through out the development process will be a variation on
the waterfall life cycle. As the requirements for the project are unlikely to change
dramatically this methodology will fit the project. If the project looked like the requirements
would be changing often a more agile methodology would have been chosen. The waterfall
lifecycle works by following a strict path through the development process not moving on to
the next stage until the previous stage has been completed. The stages for this project will be:
The first stage of the project will involve researching into existing systems, user expectation
and then drawing up the requirements of the project.
Once we have the functional requirements have been decided upon the second stage will
involve research into the non-functional requirements of the project for instance security and
accessibility.
Once the functional and non-functional requirements have been decided upon and the
technologies to be used has been decided the system will be design.
Once the design process has been completed the implementation stage can begin, although
there will be no formal test driven development for this project when new features are added
or code is edited the system will be tested to ensure that no bugs have been introduced into
the program.
Once the implementation has been completed the entire system will be thoroughly tested.
11
8 Project requirements
After analysing existing system to see which of there feature were useful and how they could
be improved, there was also a small amount of research done into finding out what user of the
existing systems felt would improve the service offered to them. From this research the
requirement for this project where drawn up.
It was decided when the website was produced for this project will allow client to sign up to
the site enabling them to purchase tickets quicker by limiting the amount of forms they have
to fill in when purchasing the tickets as most details could be held in the database.
Neither of the two website offering email updates attempt to personalise emails to the users
tastes in music. This project will attempt to make the emails to client a little more personal by
sending them emails inform them on events for genres they have shown an interest and the
system will also send out birthday emails informing clients events happening close to their
birthdays. Hopefully the personal touch of the website will keep the site ahead of competing
websites.
To improve on the search facilities offered by the existing systems. This project will over a
basic search to allow users to make a quick search of the concerts and an advanced search on
a separate page. so that users can restrict the search further.
The search parameter will be made up of the most useful search parameters from existing
systems.
12
8.1 Use Case Diagrams

Use Case Diagrams were drawn up to aid in the gathering of functional requirements. Figure
4 shows the Use Case Diagram.
Figure 4 The User Case Diagram
13
8.2 Functional Requirements

After drawing up the Use Case Diagram the following functional requirements were decided
upon.
FR1 Allow all registered users to purchase tickets for concerts.

FR2 Allow someone to register to become a user.
FR3 The system will send out automated emails to validated users.
FR4 The user signup form should test that the form is filled in by a human and not a
computer program.
FR5 Allow admin/staff users to add:
Venues
Bands
Concerts
Cities/Towns
Genres
FR6 Allow admin/staff users to edit and delete:
Venues
Bands
Concerts
FR6 The System will allow for semi automated emails, including:
Genre update emails
Birthday emails
Band Update emails
FR7 The system will allow clients to search for concerts by:
Date
A set of dates
Genre
Band
Venue
City/Town
FR8 A client user should be able to edit some of their information
Contact Details
o Address
o Telephone Number
o Email address
Credit Card Details
Password
FR9 The system will allow admin/staff users to make changes to certain settings
including:
Database
o Username
o Password
o Database Name
Style and Formatting, without having to edit any PHP or CSS code.
FR10 The website should be simple to use for both client and staff so that a manual is not
required for either user, although some tool tips may be required on the
administration side of the site.
FR11 The system will adhere to World Wide Web Consortium (W3C) Web Accessibility
Initiative (WAI) level AA web accessibility guidelines.
14
8.3 Extra Functionality

8.4 Security
Programming for the Internet requires programmers to consider different security issues that
may not necessarily be a problem when programming for single machine programs.
Problems can occur when a perfectly innocent user types in some invalid content into a form
on your website or a malicious user of the site takes advantage of holes in your security to
gain access to sensitive data or delete/edit your database.
There are many websites that dont take these security issues seriously as shown in research
from [9]:
Results of four years of penetration testing on more than 250 web applications including e-
commerce, online banking, enterprise collaboration, and supply chain management sites. The
vulnerability assessments concluded that at least 92% of web applications are vulnerable to
some form of hacker attacks.[9]
Good practise PHP programming involves checking all user input, including checking that a
user has not entered incorrect data. Programmers should test not only for invalid input, for
instance a user entering an invalid date, or a string when an int is required, but also that a user
is not entering malicious content into your form.
One of the biggest problems for high profile websites is Denial of Service (DoS) and
Disrupted Denial of Service (DDoS) Attacks. This is a type of attack by virus programmers
and hackers to bring down the servers running web services by making large numbers of
requests on the server in a hope to overload it and make it crash. This sort of vicious attack
cannot be defended against by programming. This sort of attack needs to be dealt with by the
server when the attacks start.
8.4.1 Structured Query Language (SQL) Injection

A malicious user of your site may attempt to replace your SQL query with their own by
entering their own SQL statements in to the form field on your website. This could allow the
malicious user to add, edit or delete data in your database when they should not be able to.
SQL queries are so insecure because most of the time they require a user to make a selection
or enter a string on a form to complete the SQL statement before it is used to query the
database. Most users will use a form or search facility on a website as they are intended to be
used. However a malicious users see web forms as an opportunity to attempt to create their
own SQL statements and use your program to query their SQL statements on your database,
instead of your intended SQL statement.
8.4.1.1 Preventing SQL Injection

The main way to protect a website again SQL injection attacks is to ensure that SQL
statements are constructed carefully when the variables are received from the users. This can
be done by removing any characters that can be used by a malicious users to construct their
own SQL statement to be queried on your database.
Implementing layers of abstraction between user input and the SQL statement being queried
on a database there are methods available in PHP for assisting with this.
15
8.4.2 Cross Site Scripting (XSS)

For this method of hacking a hacker uses forms on your website to introduce malicious
markup or client side script (i.e. Java Script or VB Script) then relies on other users of the site
activating the code. A cross site can be used for session hijacking and stealing users account
details
There are two types of Cross Site Scripting (XSS). The first is remote site to Application site.
This type of attack is not initiated on your site but from a link on another website or in an
email. A user is convinced to fill in a form or follow a link which contains the malicious code.
This code now has its affect on the page the user is forwarded to.
The second type of XSS attack is application site to same or remote site. This method relies
on what the malicious user enter into a form on your website being displayed to other users of
your site. The malicious user enters the markup or script into a form and that information is
subsequently displayed elsewhere. The malicious user then waits for another user of the site
to activate the script by following a link or with extra coding even just hovering over a link.
8.4.2.1 Preventing XSS

The use of POST requests make a site more secure from XSS attack than using GET requests.
So web site developers should use POST requests as much as possible to strengthen their
websites again XSS attacks.
Another method of protecting against XSS attacks is to not allow any HTML markup to be
entered into forms on a website unless it is absolutely necessary. Any HTML markup can
simply be removed by the program processing the incoming data. If HTML input is required
then rather than allowing all tags to be used filter, input and remove certain tags, for instance:
<applet>
<embed>
<script>
<object>
Scripts should also remove attributes from the tags as these can contain Java Script.
Programs should allow filter and URLs that are inputted. Normal procedure for many web
applications is to remove any GET variables from the end of the URL.
8.4.3 Session Hijacking

Session hijacking is when a malicious user of a site sets up valid sessions on that site to gain
access to the site without having to give a username or password to login.
The idea of a session was devised to allow for variables to be held in between
communications with the servers and clients. Before sessions HTTP was a completely
stateless protocol, meaning there was no way for the server to remember what clients it has
been communicating with and what it has sent to the server and the client has no memory of
which server it has been communicating with and what it has sent. Sessions were introduced
to allow information to be remembered between communications.
The session data is held on the server and given a unique session ID which is sent to the
client, then the client references this session ID when it communicates with the servers.
Anything saved as a session variable is stored in a temporary file on the server named with
the session ID.
16
The session ID can be stored by the client in two ways. The first is to store it in a cookie if
they are enabled. If cookies are disabled then the session ID can be appended onto the end of
the URL as a $_GET variable.
There are a number of different ways for hackers to intercept the session ID. They are:
8.4.3.1 Listening to network traffic

This is the simplest way for a hacker to collect valid session IDs with simple software that is
freely available on the Internet used by network administrators for legitimate reasons that
allow users of the program to intercept and read all network traffic.
8.4.3.2 Phishing, forwarding and proxies

These forms of session hijacking convince the users browsers it is connecting to one server
when it is actually connecting to another.
Hackers using these methods can often get users to click on a seemingly innocent link for the
website they wish to hijack sessions on, but the link does not go to the site it link claim to
instead it forwards the user onto the hackers server which then forwards the user on to the
site they thought they were going to. Now the hackers server is setup as a proxy in-between
the client browser and real websites server and is able to collect all session ID and any other
information sent between the client and the server including user names, password or credit
card details. Internet users can spot a link that does this by its long URL, figure 5 shows an
example of a Phishing URL. To the less experienced Internet user the domain looks like it is
barcalys.co.uk when actually it is manicte.com.
http://www.barclays.co.uk.customercare.goto.manicte.com/r1/b/
Figure 5 an example Phishing URL.
However many users of the Internet are now wary of the long URLs that are used by hacker
for such methods.
Hackers are also making use of the ever-increasing number of available Wi-Fi connections in
public places such as pubs, station, cafes and airports. There are two methods hackers use to
intercept session ID and user information on such networks. The first is to set the network up
so that all Internet connection goes via a proxy server on the network that collects all the data
being transmitted over the network. The second method is a little more complicated to set up
and involves the network vender configuring the networks Domain Name Server (DNS) by
hand so that when a user enters a URL in their web browser, they believe they are being sent
to the real website when actually they are not and again a proxy is being set up and the data
being recorded at the proxy.
8.4.3.3 Session Fixation

A hacker can make use of the facility for allowing session ID to be passed as $_GET variable
and create a link with a falsified session ID in the URL. An example of this type of URL can
be seen in figure 6. When a user of the site uses the link to get to the website and logs in the
session ID that the hacker made up will know be a valid session ID that the hacker can use.
www.example-site.com?SESSID=1234
Figure 6 An example URL used for session fixation.
17
8.4.3.4 Preventing Session Hijacking

There are number of different ways to prevent session hijacking and abuse, including the
following;
8.4.3.4.1 Secure Socket Layer (SSL)

The use of SSL is the most highly recommended method for preventing session hijacking.
This is because any data being sent between the client and the server and visa versa is
encrypted so users are protected against hackers that are listening in on the network traffic.
8.4.3.4.2 Disabling the use of session IDs as $_GET Variables

As one of the big security holes in the passing of session IDS is that they can be sent via
$_GET variables programmers may decide to disable the ability to pass session ID as $_GET
variables. This can be done with some simple programming.
8.4.3.4.3 Session Timeout

Session cookies (cookies used to hold the session ID) are by default set to exist up until the
browser using them is closed. It is possible for a programmer to override this so that a session
will only last for a set amount of time, which is set in seconds.
This method makes it difficult for a hacker to hijack sessions if they are using proxy or
forwarding methods to collect session ID, as by the time they have analysed the data the
session could have became invalid.
However there are programs that allow hackers to do real time hijacking meaning that the
session ID are found faster and may still be used. This method does not protect against this
type of attack.
8.4.3.4.4 Regenerating Session IDs

When a user logs in or logs out of a website the session ID they are using should be changed.
This makes the session ID used from one state invalid and the new state has a completely new
session ID. This method of protection stops hackers using session fixation.
8.4.4 Password Encryption

All of the passwords for both staff and client sides of the site will be stored in the database. In
case a hacker manages to gain access to the database or a malicious employee gains access to
the database, all the passwords need to be encrypted so that they can not be read or used. This
is particularly important as many people that use the Internet only use one or two different
passwords enabling any hacker to make use of this information to gain access to a users
email account or another Internet service. There are a number of different types of encryption
available with PHP including:
MD5
Sha1
CRC32
Blowfish
Passwords should never be encrypted with a reversible encryption and you should only use
known encryption like the method listed previously rather than making up your own
encryption algorithm.
8.4.5 Secure Socket Layer (SSL)

Normally any webpage served up by a HTTP server is not encrypted so any content can be
simply read if any transmissions are intercepted. Many websites that deal with sending and
18
receiving of data including address, credit card and other personal data between clients and
servers. do not want this information easily intercepted. So they want to implement some kind
of security of the connection between the server and the client machine or encrypt any data
being sent between them.
SSL requires the web server hosting the website being set up to use SSL; it also requires a
third party to sign the certificate to certify the web server is who it says it is. Finally the
programmer of the website has to implement a website that sends the data via the SSL
connection
8.4.6 Allowing only human users

This is a very popular new idea for websites and has only been seen in extensive use in the
last two years. Websites use Text Image CAPTCHAs (Completely Automated Public Turing
test to tell Computers and Humans Apart), Audio CAPTCHAs and Cognitive CAPTCHAs.
These are used on signup forms to test that the form has been filled in by a human sitting at a
computer rather than an artificially intelligent program.
The CAPTCHA test was invented by a British mathematician called Alan Turing in 1950
when the scientist started to conceive the possibility of artificially intelligent computers.
8.4.6.1 Text Image CAPTCHAs

A Text Image CAPTCHA uses an image of text that has been distorted in some way to ensure
that a computer program cannot recognise text. The user enters the characters into a text field
and the backend program ensures that both of the strings match before the program continues
to execute.
These strings are randomly picked and an image dynamically created by the underlying
program each time the page is loaded. It is done this way to ensure that there is a low change
of repetition of the string and make the program secure. If the program was to randomly select
an already created image from a file it could be possible a malicious user gains access to the
folder and uses the knowledge to break the security of the program.
The images are not just made up of plain text string. The program also distorts the text and
adds random line and pattern to help distort the image so that it is difficult to use an Optical
Character Recognition (OCR) program to recognise the text and then input its attempt to the
text field.
8.4.6.2 Cognitive CAPTCHAs

A cognitive CAPTCHA relies on the user to make a choice for a selection of possibilities.
Some cognitive CAPTCHA present the user with a selection of images and ask the user to
select which image does not fit in with the others. An example of this type of cognitive
CAPTCHA can be seen in figure 7; the odd image out in this group would be the image of the
tent as all the other images are of computers.
Figure 7 a selection of images that could be used as a cognitive CAPTCHA.
19
Another type of cognitive CAPTCHA shows the user an image and then the user is asked a
simple question about the given picture. An example of this type of cognitive CAPTCHA can
be seen in figure 8, A question about this image could be what colour are the clowns
trousers? Or what colour is the clowns hat?.
Figure 8 a picture of a clown that could be used as a Cognitive CAPTCHA
The use of images in cognitive CAPTCHA is limited as the time it takes to collect the images
and write the program to test users responses is too long
So, another form of cognitive CAPTCHA has been developed that uses plain text. This
enables it to be read by a screen reader therefore making the CAPTCHA more accessible.
There are a number of ways that this type of plain text cognitive CATPCHA can be
implemented, the simplest form of which can be seen on the Warwick University blog site
(http://blog.warwick.ac.uk). The user is asked to answer a simple question, for instance; what
colour is an apple? Or, how many wheels does a bicycle have?
The second variation of the plain text CAPTCHA is to misspell a word having white space
between each letter to ensure a screen reader will read each letter separately. Then the user is
asked to enter the correct spelling of the word.
The final method make use of a language that has developed from chat room known as L33T
SP34k (elite speak), or a language originating from short message service (SMS message or
text message) messaging and chat rooms, that is know as text speech. The user is shown a
word or sentence written in this language and asked to translate it into English.
8.4.6.3 Audio CAPTCHAs

Audio CAPTCHAs are an alternative to the visual CAPTCHAs. The user is played an audio
file usually consisting of a word or string of random letters. The user is then asked to enter the
word or random string into a text box.
Many audio CAPTCHA correspond with the visual CAPTCHAs so that answer is the same
for both the visual and audio CAPTCHAs.
Many audio CAPTCHAs like the visual CAPTCHAs use distortion of the sound file to make
it more difficult to use voice recognition software to crack the CAPTCHA. This distortion
includes static and other sounds like voices.
An example of an audio CAPTCHA is used for the hotmail signup process

(www.hotmail.com).
20
8.4.6.4 CAPTCHA Accessibility and usability

For reasons of accessibility and usability websites must use a combination of two
CAPTCHAs, one that makes use of image which can be used by people who have no visual
disabilities, and an audio CAPTCHA for users with visual disabilities, as for this image you
obviously do not want to use an alt tag. For usability reasons you can not just use an audio
CAPTCHA as you have to take into consideration that not all computers have audio output
devices.
The W3C
This type of visual and textual verification comes at a huge price to users who are blind,
visually impaired or dyslexic. Naturally, this image has no text equivalent accompanying it,
as that would make it a giveaway to computerized systems. In many cases, these systems
make it impossible for users with certain disabilities to create accounts, write comments, or
make purchases on these sites, that is, CAPTCHAs fail to properly recognize users with
disabilities as human.[12]
Chris Snyder and Michael Southwell also believe that use of only audio CAPTCHA is
inaccessible:
Audio Captchas may seem like a viable alternative to some of the usability disadvantages of
the visual CAPTCHAs. [7]
Despite the propaganda promoting audio CAPTCHAs as a viable alternative to visual ones,
in truth this kind of CAPTCHA simply imposes a different kind of usability challenge, and
indeed the universe of users with audio disabilities or deficits is even larger than that with
visual disabilities.[7]
For audio CAPTCHAs, the required capabilities extend beyond the physical and cognitive to
the hardware and software installed on users computers. [7]
8.4.7 Verifying your users

Many websites send out emails to new customers when they sign up to ensure that the
information the user has entered into the form is true to that person. Most websites send an
email to the address specified in the form. The email contains a link that the user clicks on
that validates the account.
8.4.8 Maintaining a secure environment

A major part of ensuring that your web site is secure is to setup your server, database and
PHP correctly. This involves not only written secure programs but also ensuring that the
website is set up correctly and the latest patches for the web server, database and PHP are
installed to ensure all known security holes are blocked
8.4.9 Security Functionality

The intention for this project is to attempt to make the application as secure as possible by
implementing most of the methods indicated above.
The application should be protected against cross site scripting, SQL injection and session
hijacking attacks.
As both staff and client users do not need to enter HTML tag or SQL statements, all input will
be filtered to remove HTML tag and any special characters.
21
Commenting of code can be dangerous so all commenting will be kept within the server side
scripting. This is done to ensure that a malicious user cannot read comments that could help
them find security holes easier by just viewing the source.
To protect against session hijacking all sessions will have a set lifetime so that a clients user
sessions will only last for 20 minutes and staff user sessions will last for an hour allowing
them to get work done. The session ID will also be changed when the user logs in and out of
the website.
There are security measures that are out of developers hands especially if they do not have
large amounts of control over the web server. Things like firewalls play an important part in
securing web applications as do whether they have SSL at their disposal or whether error
messages from server side scripting is displayed.
22
8.5 Web Accessibility and Usability

Web accessibility is not a recent idea. The WC3 WCA 1.0 specifications have been around
since early 1999, but it has only recently been wide spread public knowledge.
The British Standard Institute defines accessibility of websites as

Ability of people with disabilities to perceive, understand, navigate and interact with
websites[1]
Jakob Nielsen has a view on web accessibility that:

In addition to regulatory compliance and common human decency, there are hard-nose
business reasons to web designs accessible for users with disabilities. Often disabled users
become very loyal customers once they find vendors who give them good service and
accommodate their special needs.[11]
8.5.1 Web Usability

Web Usability is not the same as accessibility. It is more about ensuring that your site is
simple to use, easy for the user to get to the information they require quickly and ensure that a
large target audience is able to use the site.
Jakob Nielsen make a good point on the reason for making a usable website:
Usability rules the Web. Simply stated if the customer cant find a product then he or she
will not buy it.
The Web is the ultimate customer empowering environment. He or she who clicks the mouse
gets to decide everything it is so easy to go else where; all the competitors in the world are
but a mouse click away.[11]
One major part of ensuring a website is usable is to ensure that the website is cross browser
compatible.
8.5.2 Accessibility Law

There is no law in the United Kingdom that states that websites must be accessible and as yet
there have been no cases against companies with regards to the accessibility of their website,
so nobody has a benchmark of how accessible a website need to be. However there are parts
of the Disability Discrimination act 1995 revised in 2005 that could be used to cover websites
if someone wished to bring someone to court for not making their website accessible. For
instance the law states:
Disability Discrimination act 1995 Part III section 19.

(1) It is unlawful for a provider of services to discriminate against a disabled person.
(a) In refusing to provide or deliberately not providing, to the disabled person any service
which he provides, or is prepared to provide to members of the public;[7]
This could include a large number of websites on the Internet including Sales Websites
(Tesco, Play, Amazon, Ticket Master, this project) or online banking systems
8.5.3 Online Testing

The Watchfire website (http://webxact.watchfire.com) offers a web site accessibility testing
service. The service is good but limited as a lot of the concepts require a human to make a
judgement on the content rather than being able to test for it by a program. It does warn the
user that they may be missing accessibility that covers these and encourages the user to keep
to the remaining unchecked guidelines.
23
8.5.4 Web Content Accessibility Guidelines 1.0 (WCAG 1.0)

WCAG 1.0 is the World Wide Web Consortium (W3C) guidelines for producing accessible
web content.
The guidelines are split up into three different levels, to denote the level of accessible features
implemented on the webpage. These levels are known as priority 1 3 or Web Accessibility
Initiative (WAI) A, AA and AAA.
8.5.4.1 Priority 1
Priority 1 or WAI A guidelines are pretty simple to conform to and are generally ensuring that
web site developers conform to general good practises of web site design, for instance:
Ensure that all non-text elements on a website have a textual equivalent.
Produce web pages that are readable when style sheets are not applied.
When using data tables ensure that row and column headers are identified.
The priority 1 guidelines for web accessibility are pretty simple to meet and a reasonable
requirement for this website is to meet the guidelines set out by the W3C.
8.5.4.2 Priority 2
Priority 2 or WAI AA guidelines are a little bit more difficult to comply with. Although they
still cover some of the good practises that most web developers adhere to, they also include
some specific to users needs including things like;
Ensuring that background and foreground colour contrast enough so that they can be
viewed on a black and white monitor or by a colour-blind user.
Avoid using blinking content.

The priority 2 guidelines require a little extra programming other than regular good practise
web site design. They also require some training on the part of any people that will be
entering data in to ensure the upkeep of the website. However despite these, it is best to
ensure the priority 2 guidelines.
8.5.4.3 Priority 3
Priority 3 or WAI AAA can be a lot more difficult than the previous two priorities. A lot of
the recommendation can not be judged by a program such as an online testing application.
Examples of the recommendations are:
Expand Acronym and abbreviation with the appropriate Tags.
Indicate the language the document is written in.
Provide Summaries for tables.
The priority 3 guidelines are a little more difficult to meet but are possible to meet with some
extra programming on the site design, however, they increased workload on data entry staff.
For this reason it will not be a requirement to meet priority 3 guideline for the website.
8.5.5 Publicly Available Specification 78: Guide to good Practise in

Commissioning Accessible Websites (PAS 78)
PAS 78 was released on the 8th March 2006. It was developed by the British Standards
Institute (BSI), and is the BSI recommendation on how to construct and test a website for
accessibility.
24
The document points out that having an accessible website does not just benefit disabled
users. It also makes it easier for non-disabled people to use the website. It also points out the
following the WAI guidelines can also increase your websites visibility to and rating for
search engines.
This document confirms my belief that automated tests can produce false positives and the
user testing will find problems that automated testing will not.
The document suggests that user testing and site design be done with disabled and non-
disabled users to guarantee website designers are ensuring the website is usable and
accessible from the beginning of development.
Overall the document seems to be aimed at management or corporate level rather than web
developers or web development companies. The document is aimed at what it defines as
website commissioner:
Individual or organisation responsible for designing and building a website or web
content.[1]
The document recommends not to use just one form of testing. It recommends using a number
of different forms of testing including:
Conformance Testing this testing requires you to check that a website meets the
guidelines of any the website claims to meet. E.g. WAI AA
User Testing this testing involves getting a number of target users. These users are
given a selection of different tasks to perform when using the website then how the
users get on with these tasks is recorded.
Along with user testing and conformance testing the document recommends expert reviews
throughout development as
They are useful for identifying quality and consistency issues not typically identified during
user testing. However , they do not find the same type or number of problems as user testing;
[1]
A lot of the suggesting made in the document seems to be about giving individuals or
organisations looking to make their website accessible things to think about while the website
is being produced, from conception to the finished website.
8.5.6 Conclusion
To ensure that a website is accessible the best form of testing is a combined one, making use
of both the testing methods.
After researching into web accessibility it was felt that extra functional requirements were
needed to ensure that the site could adhere to WAI specifications. These are covered in
function requirement FR11.
The testing of the website will also include a number of user testing task to aid in the
development of an accessible and useable website.
25
8.6 Online Finance Systems

As the system needs to deal with financial transactions when customers buy tickets, research
was needed into online banking and payment systems and how the online ticket sales system
could interact with the different systems available.
Many banks on their website recommend using a third party payment solution such as PayPal
or World Pay.
It is possible to become a credit card vendor that allows you to accept payment from credit
cards that you are a vendor of.
8.6.1 PayPal and WorldPay

PayPal is the most well known third party online payment solution, a popular choice for users
of EBay, and is very reliable and secure. WorldPay is another third party online payment
solution similar to PayPal. It is used by many small businesses to receive payments over the
Internet, including the university (http://www.aber.ac.uk/systems/buyquota/).
PayPal have made it simple so even the least experienced website developers can accept
payments on their website into the PayPal account, by creating the code for the user to copy
and paste into their website where it is required.
However this type of payment solution would make a multinational sales company web site
look a bit unprofessional and cheap. Would you consider buying a CD from a website that
used PayPal? On the upside, for a new unknown website it may install customer confidence in
that customers are not being conned and will receive their tickets and imply that it is not a
spoof site.
8.6.2 Credit Card Vendor

All major credit card companies offer a system that allows companies to accept payments on
their websites. These services are used by many major Internet companies.
8.6.3 Conclusion
For this system the best type of payment system would be for the website to become a vendor
for most if not all of the major credit card companies. This would allow a large majority of
the UK population to purchase tickets via the My Tickets system, and many people now are
very comfortable using their credit card to purchase all sort of items and services over the
internet as long as they can tell that the website is secure.
I felt that although online payment systems such as PayPal and WorldPay are extremely
useful and have a good reputation on the internet, they are used by smaller companies.
When the system is being programmed empty function will be put in place, so that it is ready
for the extra programming involved with taking a payment from a customers credit card.
26
9 Implementation
9.1 Technology
Before any programming could be done decisions needed to be made on which technologies
should be used to program the project with. The following is a critical evaluation of the
different programming languages that could be used to program such an online application.
9.1.1 Java Enterprise Edition

Some research was done into different technologies that could be used to create the online
ticket sales system. The first technology that was considered was J2EE or Java Enterprise
Edition which is Javas specification for distributed programming. This was considered
because of a prior knowledge of the Java Programming language, but after some
experimentation with J2EE I decided not to use this technology because of difficultly with
implementation a project before. The problems occurred when trying to get the Web tier
(JSPs and Servlets) to communicate with the EJB (Enterprise Java Bean) tier.
9.1.2 ASP
ASP was noted as a possible language to use for server side control of the site. However due
to no prior knowledge of the language it was discounted.
9.1.3 PHP Hypertext Pre-processor

PHP Hypertext Pre-processor (PHP) is an open source Scripting language. The latest edition
of PHP (Version 5) has implemented Object Orientation.
This was considered for the project due to a small previous knowledge of the scripting
language as well as a want to expand and improve knowledge and understanding of the
language.
Although there was some previous knowledge of the language this was quite limited as most
PHP sites that I have developed have only been very basic. Using the language to create some
basic input forms and put the incoming values into a database. From this basic insight into
PHP it was felt that with some more research and experimentation this would be an excellent
language to use to make the online ticket sales system.
Most Web Hosting companies offer PHP on their servers as default and include a MySQL
database so the program will be written in PHP and interact with a MySQL database to store
and retrieve information that is necessary for the running of the program.
9.1.4 Cascading Style Sheets

Research was done into Cascading Style Sheets (CSS) and the different ways it could be used
to control both layout and style of the site. There was some experimentation with using <div>
tags and CSS to controlled layout, as well as using tables to control layout with some CSS to
format things like alignment and colour.
Both approaches give web developers a lot of control of site layout. However pure CSS
layout allows the designer to complete separate style and layout from content, whereas table
based layout does not allow for complete separation of the two. This means that if a site uses
pure CSS layout it could look completely different as elements of the site can be moved to
any part of the page unlike tables that have a more solid construction and do not allow for
this. A good example of how much control developers using pure CSS layout have is the
website CSS Zen Garden, the creation of CSS expert Eric Meyers, which is not only full of
27
CSS tutorial but also uses its homepage to showcase different CSS designers, meaning the site
is never the same.
The use of table layout currently has one major advantage over pure CSS layout and this is
the cross browser compatibility. Because of it more stable and solid structure a website that
uses tables will look near enough the same as most commonly used web browsers. This is
because although all current versions of web browsers support CSS layout, therefore each
browsers development team interpret the CSS standards for layout a little differently, if
developers wish to use pure CSS layout they must introduce hacks into their CSS using
scripting languages such as PHP to check which browser a user is using and on that
information decide which parts of the CSS to serve up.
After researching into CSS, particularly its use for layout, it was decided that it would be best
to use pure CSS layout to control the website as this will make expansion and updating the
site easier in the long run.
28
9.2 Website Design and layout

Users (staff) will be able to make changes to the design of the site without editing the live
website code if they wish to make a change to the site aesthetically, for instance, font size,
font colour or background colour. Originally there was a plan to use PHP to include to include
files that made up elements of the site such as the header, navigation panel or search panel.
This was considered the best way to allow the staff users to make design changes to the
website, until research into CSS found a practise known as Dynamic CSS where developers
use PHP files as CSS files to allow the attributes to be changed dynamically and quickly by
site developers and maintainers of a web site without having to make changes to HTML or
CSS. This allows staff users to make changes to the style without much knowledge of HTML
or CSS.
9.3 Human Computer Interaction

Human Computer Interaction (HCI) needed to be seriously thought about for this site not only
for reasons of accessibility but also to keep users interested and allow them to get to the
information or page they require as quickly as possible.
This sort of site should not be off the wall or extremely different. This site needs to be simple
and conform with design standards; not using things such as flash animation or complex
design styles.
The website layout does not change between pages as this can confuse users as suggested by
[6]
User interfaces need to be consistent. It is difficult to emphasize this enough. The user
should not be expected to remember a different sequence of events for similar actions.[6]
Menus stay the same from page to page except for a small change when a user logs on to the
websites. This is done so that users do not get confused or frustrated navigating through the
site.
The number of options on the menu has also been kept to a minimum as [6] suggests that:
There is a desirable number of entries for each menu which is determined by human
cognition, for example. It is very important to think in terms of the magic number 7 plus or
minus two. If more menu items are needed than this then it is necessary to subdivide large
menus and menu entries.[6]
This was an issue on the client side of the site so the options were broken down into sections;
this can be seen in figure 9.
29
Figure 9
30
9.4 Site Layout

The site needed to be split into two separate parts, the first for the clients to see. This part of
the website will allow clients to sign up for the web site, search for concerts and purchase
tickets for the concert.
The other part of the website for administrators, will allow admin staff to add, edit and delete
content
The two sites could be hosted on completely different servers as long as they can both
connect to the same database. As it is, the admin part of the site is held in a sub directory
within the client side of the site.
9.4.1 Client Side

The client side of the site only has a few web pages and the main bulk of the programming is
down in controller.php and classes that controller.php uses.
There are some small amounts of code in main pages of the website to retrieve data from the
database to build up list, menus and other page content. Almost all of the forms on the client
side of the site are sent to controller.php where the input is processed, apart from the search
forms which both get processed in results.php. controller.php acts as front controller which
calls method is data objects which access the database. Once the processing is complete the
user is then forwarded to a page in the main site depending on what the user was doing and
whether the processing of the data was completely successful or not.
Figure 10
9.4.1.1 Client Sign Up

Figure 11 shows the flow of data involved in the client sign up process.
1. The clients details are sent as $_POST variables to controller.php
2. controller.php checks all the variables for null values, if there are any null values, the
CAPTCHA string do not match or the passwords do not match, the user is sent back
to client-form.php.
3. If all the all the values are all ok controller.php the add_client() function is called.
4. The database is checked for any user names similar to the one the user has just chosen
5. If a user name similar the one the user has just entered already exists the user is sent
back to client-form.php
31
6. The database is checked for the email the user just entered.
7. If the email already exists in the database the client is forwarded client-form.php
8. The clients details are added to the client table.
9. if the clients details are not added to the client table the user is forwarded to client-
form.php
10. If the clients details are added correctly, the card_setup() function is called, which
inserts the clients credit card details into the card table.
11. If the credit card details are not added to the card table the user is forwarded to
unsuccess.php and the database is rolled back.
12. If the credit card details are added to the card table the genre_setup() function is
called which add the clients choices genre to the genre table.
13. If the genres are not added to the genre table the user is forwarded to unsuccess.php
and the database is rolled back.
14. If the genres are added successfully the client_varifacation_email() function is called
which emails the client with the email they can use to verify their account.
15. If the email is not sent the user is forwarded to unsuccess.php and the database is
rolled back.
16. If the email is sent the user is forwarded to thanks.php.
Figure 11
9.4.1.2 Booking Tickets

Figure 12 shows the flow of data involved in booking tickets.
1. The desired concert number passed to tickets.php as a $_GET variable
2. Number of tickets and concert number passed to purchase.php as $_POST variables
3. Number of tickets, concert number and posting address passed to controller.php as
$_POST variables.
4. Get the current number of price of tickets from the concert database and work out the
total price of the booking.
5. controller.php calls the check_availability() function in the purchase object passing
the number of tickets, concert number, client number and posting address as variables
6. Database checked for any bookings for the same concert and user as users can only
purchase one set of tickets for each concert.
7. If the user already has tickets they will be sent to unsuccess.php and the database is
rolled back
8. Information on the concert is retrieved from the concert table.
32
9. If the number of tickets remaining minus the number of ticket in the booking is
greater than or equal to zero, the number of tickets remaining for that concert is
edited in the concert table.
10. If the number of tickets remaining would equal less than zero the use would be
forwarded to unsuccess.php and the database is rolled back
11. The user is then returned to controller.php
12. controller.php calls the make_purchase() function in the purchase object passing in
the total price of the purchases.
13. The purchase data is added to the database.
14. If the insert into the database fails the user is forwarded to unsussess.php and the
database is rolled back
15. If the data is inserted into the database successfully the function returns to
controller.php
16. controller.php calls the receive_payment() function. This function would be where
payments would be taken from their credit cards if the program was setup to take
payments
17. The payment for the tickets is taken
18. If the payment is unsuccessful the user is forwarded to unsuccess.php and the
database is rolled back
19. If the payment is successful the function returns to controller.php
20. controller.php calls the confirm() function in the purchase object.
21. The information for the booking is retrieved from the booking table.
22. The clients information is retrieved from the client table
23. The concert information is retrieved from the concert table
24. The band information is retrieved from the band table
25. An email is constructed confirming the booking and sent to the client.
26. If the email is not sent, the user is forwarded to unsuccess.php and the database is
rolled back
27. If the email is sent, the function returns to controller.php
28. The user is forwarded to thanks.php
Figure 12
33
9.4.2 Administrator Side

The administration side of the site has the same flow of data as the client side where all of the
forms data is sent to controller.php and the data is processed. The only difference is that there
is a little more programming in the controller that accesses the database as well as the classes.
9.4.2.1 Adding a Band

Figure 13 shows the flow of data involved with the process of adding a band.
1. The band data is sent from the form on concert-form.php to controller.php. The data
is checked for null values.
2. If there are null values or the image file is too large the user is forwarded to concert-
form.php
3. controller.php checks the database for any band with names similar to the one
attempting to be added.
4. If the database has any bands with a name similar to the band being added the user is
forwarded to client-form.php.
5. controller.php calls the add_band() function in the band object.
6. The function attempts to upload an image to images/artist/.
7. If the upload is unsuccessful the user is forwarded to band-form.php
8. If the upload is successful the bands information is added to the database.
9. If the data is not added to the database successfully the user is forwarded to band-
form.php
10. If the band is added successfully the user is forwarded to band-list.php.
Figure 13
9.4.2.2 Editing a Venue

Figure 14 shows the flow of data involved with the process of editing a venue.
1. The venue data is sent from venue-form.php to controller.php. The data is checked
for null values.
2. If there are any null values the user is forwarded to venue-form.php.
3. The venue table is checked for any other venues of a similar name in the same town.
4. if there is a venue with a similar name in the same town the user is forwarded venue-
form.php.
5. The edit() function is called in the venue object.
6. The venue data is updated in the database.
7. If the update is unsuccessfully the user is forwarded to venue-form.php
8. If the update is successful the user is forwarded to venue-list.php.
34
1 Controller.
venue-form.php 2, 4
3
php
venue
5
6
7 Venue.php
venue-list.php
Figure 14
35
9.5 Site Design (Page Layout)

When the site layout was designed accessibility and usability were taken into consideration
There are three 1 pixel by 1 pixel transparent images that are hidden in the top right. These
are linked to particular parts of the page to aid blind and partially sighted users of the site to
navigate quickly around the page. These links are links to anchor points on the current page.
This allows users of voice browsers to skip to the section of the page they require. These links
are also set with an access key. This allows users to hold down the ctrl button and press the
assigned access key and the user is quickly taken to the anchor point.
The anchor points are located at the top of the navigation div, the content div and the basic
search div.
The Text Only version links to the same page, but a different CSS is used to render the
page. This CSS is pretty simple and it only really affects images; these will be hidden from
view although any voice browsers should still read out the alternative text.
With the use of CSS layout it is possible to have your page content completely out of order
then use the CSS to control where it is placed on the page. This is bad practise and does not
comply with WAI guideline 6.1
Organize documents so they may be read without style sheets. For example, when an HTML
document is rendered without associated style sheets, it must still be possible to read the
document. [4]
For this reason the XHTML was written in the order that it should be read on the page.
36
9.6 Database Design

The database that was use for this project was MySQL. Figure 15 shows the enitity relation
ship diagram for the database used by this website.
Figure 15 A diagram showing the database design.
9.6.1 Client
The client table is used to store the clients details.
Field Name Field Type Field Length Comments
clientNum bigint 20 Primary Key, Auto incrementing, not
null
Surname varchar 30 The customers surname, not null
firstName varchar 30 The customers first name, not null
DOB Date The customers date of birth, not null
addLine1 varchar 50 The first line of the customers
address, not null
addLine2 varchar 50 The second line of the customers
37
addess customers
town varchar 30 The customers town, not null
county varchar 30 The customers county, not null
postcode varchar 9 The customers postcode, not null
telNo varchar 13 The customers telephone number, not
null
email varchar 50 The customers email address, not null
userName varchar 20 The customers user name not null
password varchar 32 The customers password held in
MD5 encryption not null
valid varchar 6 Will equal true if use has validated
account and false if the account has
not been validated, not null
9.6.2 Card
The card table is used to store the clients credit card details
clientNum bigint 20 Primary Key and foreign key
referencing the client table not null
type varchar 25 The type of credit card e.g. Visa or
master card not null
secNum int 3 Three digit security code found on
the back of a credit card. not null
cardNum varchar 20 Card number found on credit card not
null
startDate varchar 7 The date the card is valid from not
null
expireDate varchar 7 The date the card expires not null
9.6.3 Genre
The genre table is used to store the clients chosen genres.
clientNum bigint 20 Primary Key and foreign key
referencing the client table. not null
genre varchar 20 Primary Key and foreign key
referencing the genres table. not null
9.6.4 Concert
The concert table is used to store the concerts details.
ConcertNum Bigint 20 Primary key and foreign key
referencing the client table not null
Time Time The time the concert will start not
null
Date Date The date the concert is held on. not
null
venueNum bigint 20 Foreign key referencing the venue
table. not null
bandNum bigint 20 Foreign key referencing the band
38
table. not null

releaseDate Date The date the concert ticket will be
released on. not null
releaseTime The time the concert ticket will be
release. not null
TotalTickets bigint 20 The total number tickets for the
concert. not null
RemainingTickets Bigint 20 The number of tickets not sold for
the concert. not null
ticketPrice double The price of the tickets. not null
9.6.5 Genres
The genres table is used to store all genres. Mainly used for dynamically creating menus
making the site easy to keep up to date.
gnere varchar 30 Primary key not null
9.6.6 Band
The band table is used to store the bands details
bandNum Bigint 20 Primary key, auto incrementing not
null
name Varchar 40 The name of the band, must be
unique not null
genre Varchar 20 The genre of the band
website varchar 50 The website of the band the http://
not needed.
picture varchar 30 The file name of picture
alt varchar 255 The alternative text for the image.
desc longtext The description of the band.
9.6.7 Venue
The venue tables is used to store the venues details.
venueNum Bigint 20 Primary key, auto increment
name Varchar 40 The name of the venue
town Varchar 40 The town in which the venue is
situated
capacity bigint 20 The capacity of the venue.
9.6.8 Town
The town table is used to store all town and city. Mainly used for dynamically creating menus
making the site easy to keep up to date.
town varchar 40 Primary key
39
9.6.9 Booking
The booking table hold the details of all the bookings made.
bookingNum Bigint 20 Primary key, auto incrementing ,not
null
clientNum Bigint 40 Foreign key referencing the client
table. not null
NumTickets int 11 The number of tickets required in the
booking. not null
PostingAddress varchar 255 The address for the tickets to be
posted to. Not necessarily the clients
actual address. not null
concertNum bigint 20 Foreign key referencing the concert
table. not null
totalPayment double The total amount the customer will
have to. not null
9.6.10 Staff
The staff form holds all of the staffs details.
staffNum Bigint 20 Primary key, auto increment. not null
username Varchar 20 The staff member user name. not null
Password Varchar 32 The staff member password. not null
adminLevel Smallint 6 The staff member admin level to
determine the user level of access.
not null
firstName Varchar 30 The staff member first name. not null
surname varchar 30 The staff member surname. not null
40
9.7 Implementation Process

The implementation of the system
The project makes some use of the new object orientation features available in PHP 5 a class
file can be found in the /classes directory.
9.7.1 Featured Code
9.7.1.1 Security
9.7.1.1.1 Referrers
The first most basic security check is to ensure that any requests for controller.php are only
coming from forms within the website and not from other websites.
This check is done on both the client and administration sides of the website. The code that
does this can be seen in figure 16.
$ref = preg_match("/www.digitally-scarred.co.uk/", $_SERVER['HTTP_REFERER']);

if($ref == 0)
{
header("location: unsuccess.php");
}
Figure 16 The code used to ensure that forms have not been sent from another website.
9.7.1.1.2 Input Validation

To combat against SQL injection on the part of a malicious user or a user entering in
characters that could cause problems with the program, certain character have to be removed
from any inputted. The character include:
o ;
o =
o *
o
o
There is no real need for users to enter any of these characters and some of the characters are
key to making up SQL statements so they are simply removed from any input text.
The code that also uses a regular expression <.*> to remove anything in-between < and >.
This will protect the site from Cross Site Scripting attacks.
Checking also has to be done to ensure that all required fields are not null. This is done to
ensure the integrity of data in the database.
The code that removes unwanted characters and checks for null field can be seen in figure 17.
41
$var_array = array("surname", "firstName", "dob_year", "dob_month", "dob_day",

"addLine1", "addLine2", "town", "county", "postcode", "telNo", "email",
"userName", "password", "card_type", "cardNum", "start_month",
"start_year", "expire_month", "expire_year", "secNum");
$illegal_character_array = array('/\'/', '/\"/', '/;/', '/:/', '/=/');
$error_num = 0;
foreach($var_array as &$var)
{
$$var = $_POST[$var];
$$var = preg_replace($illegal_character_array , "", $$var);
if($var == "addLine2" or $var == "telNo")
{
//Any variables listed above are not required and may be
null.
}
elseif($$var == "")
{
$error_num = 1;
}
}
$dob = $dob_year."-".$dob_month."-".$dob_day;
if($check == 1)
{
header("location: client-form.php?surname=".$surname
."&firstName=".firstName."&addLine1=".$addLine1."&addLine
2=".$addLine2."&town=".$town."&county=".$county."&postcod
e=".$postcode."&telNo=".$telNo."&email=".$email."&errorNum
=2");
}
Figure 17 The code used to test input from forms for null values and unwanted characters.
9.7.1.1.3 Sessions
When user logs in and out of the website their session ID is change automatically. When the
user logs in to the website there is a time limit set on the lifetime of the sessions. Figure 18
shows the code logging in to the site. Figure 19 shows the code for logging out.
42
$result = $new_client -> login($password_1, $clientNum);
if($result == true)
{
session_regenerate_id();
ini_set("session.cookie_lifetime", 1200);
$_SESSION['logged_in'] = true;
$_SESSION['user'] = serialize($new_client);
header("location: index.php");
exit();
}
Figure 18
if($form_id == "logout")
{
unset($_SESSION['logged_in']);
unset($_SESSION['user']);
session_regenerate_id();
header("location: index.php");
}
Figure 19
9.7.1.2 CAPTCHA
The original CAPTCHA was quite basic. The program created a simple string 6 characters
long, all in upper case using the code in figure 20
<?php
session_start();
$image = imagecreatetruecolor(60, 30);

$string = "";
//Creates a random String

for($i = 0; $i < 6; $i++)
{
$string .= chr(rand(65,90));
}
$_SESSION['string'] = $string;
$textcolor = imagecolorallocate($image, 0, 255, 0);
imagestring($image, 4, 5, 5, $string, $textcolor);
// output the image

header("Content-type: image/jpeg");
Figure 20 the code for version 1 of the CAPTCHA image.
43
This code produced a CAPTCHA image like the one that can be seen in figure 21.
Figure 21 - an example of the CAPTCHA image created by version 2 of the CAPTCHA code.
This CAPTCHA was felt to be too simple and that there needed to be more distortion to the
image to make it more difficult for an OCR program to read the string. So version two of the
CAPTCHA code was created:
<?php
function makeRGBColour($colour, $image)
{
$colour = str_replace("#", "", $colour);
$red = hexdec(substr($colour, 0, 2));
$green = hexdec(substr($colour, 2, 2));
$blue = hexdec(substr($colour, 4, 2));
$out = imagecolorallocate($image, $red, $green, $blue);
return($out);
}
$image = imagecreatetruecolor(60, 30);

$string = "";

for($i = 0; $i < 6; $i++)
{
}
$_SESSION['string'] = $string;
$font_size = 14;
$font = "arial.ttf";
$padding = 15;
$captcha_area = imageftbbox($font_size, 0, $font, $string);

$captcha_area_width = $captcha_area[2];
$captcha_area_height = $captcha_area[1] + abs($captcha_area[7]);
$image_width = $captcha_area_width + ($padding * 2);

$image_height = $captcha_area_height + ($padding * 2);
$text_x_cord = $padding;
$text_y_cord = $captcha_area_height - $padding;
$captcha_image = imagecreate($image_width, $image_height);
$background_colour = makeRGBColour('220099', $captcha_image);

$font_colour = makeRGBColour('999999', $captcha_image);
imagefttext($captcha_image, $font_size, 0, 10, 25, $font_colour, $font, $string);
44
$line = makeRGBColour('555555', $captcha_image);

for($i = 0;$i < 6; $i++)
{
$x_cord_start = rand(0, $image_width);
$y_cord_start = rand(0, $image_height);
$x_cord_end = rand(0, $image_width);
$y_cord_end = rand(0, $image_height);
imageline($captcha_image, $x_cord_start, $y_cord_start , $x_cord_end,
$y_cord_end, $line);
}
header("Content-Type: image/png");
imagepng($captcha_image);
?>
Figure 22 the code for version 2 of the CAPTCHA image.
The CAPTCHA produced code in figure 22 produces an image like the one in figure 23. To
distort the image a number of randomly positioned lines are added to the images making it
difficult to for a computer to read but a human user would be able to pick out the letters with
ease.
Figure 23 - an example of the CAPTCHA image created by version 2 of the CAPTCHA code.
Figure 24 shows the code of version 3 of the CAPTCHA program which creates a CAPTCHA
image similar to the image in figure 25.
$string = "";

for($i = 0; $i < 6; $i++)
{
}
$_SESSION['string'] = md5($string);
$font_size = 18;
$font = "arial.ttf";
$padding = 15;
$captcha_area = imageftbbox($font_size, 0, $font, $string);

$captcha_area_width = $captcha_area[2];
$captcha_area_height = $captcha_area[1] + abs($captcha_area[7]);
$image_width = $captcha_area_width + ($padding * 2);
45
$image_height = $captcha_area_height + ($padding * 2);
$text_x_cord = $padding;
$text_y_cord = $captcha_area_height - $padding;
$captcha_image = imagecreate($image_width, $image_height);
$background_colour = makeRGBColour('ffffff', $captcha_image);

$font_colour = makeRGBColour('000000', $captcha_image);
$line = makeRGBColour('555555', $captcha_image);

for($i = 0;$i < 10; $i++)
{
$a = rand(1, 2);
if($a == 1)
{
$x_cord_start = 0;
$y_cord_start = rand(0, $image_height);
$x_cord_end = $image_width;
$y_cord_end = rand(0, $image_height);
}
else
{
$x_cord_start = rand(0, $image_width);
$y_cord_start = 0;
$x_cord_end = rand(0, $image_width);
$y_cord_end = $image_height;
}
imageline($captcha_image, $x_cord_start, $y_cord_start , $x_cord_end,
$y_cord_end, $line);
}
imagefttext($captcha_image, $font_size, 0, 10, 25, $font_colour, $font, $string);
$dot = makeRGBColour('000000', $captcha_image);

for($i = 0;$i < 600; $i++)
{
$x = rand(0, $image_width);
$y = rand(0, $image_height);
imagesetpixel($captcha_image, $x, $y, $dot);
}
header("Content-Type: image/png");
imagepng($captcha_image);
imagedestroy($captcha_image);
Figure 24
Figure 25 an example of the CAPTCHA image created by version 3 of the CAPTCHA code.
46
Some of the code for versions 2 and 3 of the CAPTCHA has been taken from/adapted from
code that can be found in Pro PHP Security by Chris Snyder and Michael Southwell pages
340 342 [14]
9.7.1.3 Deleting / Updating CHANGE!!!

Any changes to the database that could affect other tables or tuples have to be checked with
programming rather than relying on the database to do the checks itself. This must be done to
maintain referential integrity throughout the database.
This check can take two forms: a cascade delete in which any tuples make reference to the
data being deleted, or not allowing the deletion of any data in the database if it being deleted
if it is being referenced elsewhere. It was decided that the latter would be the best idea so
deletion if only possible is certain parameters are met.
An example of this form of check can be seen in figure 26. This is the code that deletes
venues from the data, but venues can only be deleted if there are no concerts booked in them.
If there are they will not be deleted.
function delete_venue()
{
$sql = "SELECT * FROM venue;";
$results = mysql_query($sql);
while($venues = mysql_fetch_array($results, MYSQL_ASSOC))
{
if(isset($_POST[$venues['venueNum']]))
{
$sql = "SELECT * FROM concert WHERE venueNum =
'".$venues['venueNum']."';";
$concerts = mysql_query($sql);
$rows = mysql_num_rows($concerts);
if($rows == 0)
{
$sql = "DELETE FROM venue WHERE venueNum =
'".$venues['venueNum']."';";
mysql_query($sql);
}
}
}
Figure 26 The code used for deleting a venue testing for venue use before deletion.
47
9.8 Problems during Implementation

9.8.1 PHP
There were a number of issues with PHP that came up during the implementation of the
project.
With the latest release of PHP the programming language has now been implemented with
Object Orientation. This has its advantages and disadvantages. For instance, it does not allow
the overloading of methods and constructors which is a problem as it means you can only
have one constructor for each class. This caused a problem during development and a
decision had to be made whether to leave the constructor as an empty default constructor or
implement the constructors.
9.8.2 Accessing Objects held as a session variable

There were some difficulties accessing data objects held in session variables. This was done
to cut down on accesses to the database and to speed up the processing of pages.
Unfortunately accessing the individual variables stored in the session held object wasnt
simple. The simplest way to access them was to transfer the variable into a new array and use
that array. This had to be done on each page the variables were needed on. The code for this
process can be seen in figure 27
$client = unserialize($_SESSION['user']);
foreach($client as $one => $two)

{
$user[$one] = $two;
}
Figure 27 the code used to retrieve individual variables from an object held in a session
variable.
9.8.3 Database
During development one problem that occurred was another that was under the control of the
Web Hosting Company. The problem was concerned with the type of database table that can
be used to hold the information the system requires to work. There are two types of database
table available for MySQL. The first is transaction-safe tables (TST) which includes InnoDB
and BerkeleyDB (BDB) tables. These types of table allow the programmer to use database
transaction to ensure that any data stays in a constant state.
The other type of table is the not transaction-safe table (NTST), which includes MYISAM,
ISAM, MERGE and HEAP. The NTST tables do not allow the programmer to use database
transaction facilities. Although this makes any interaction with the data quicker, these tables
do not allow transaction to be used.
Unfortunately only the type of table available with the web hosting used was NTST not
allowing the system to easily implement database rollback automatically. Rather, the system
had to have extra programming to implement a substitute for not being able to use database
transaction.
48
9.8.4 General
Cross browser compatibility was a big problem during development. There were many
inconsistencies between the ways that web browsers rendered a page. One of the most
noticeable differences is that Internet Explorer web browsers pre version 7 do not support the
transparency of Portable Network Graphics (PNGs). So a Hack had to be found that would
force these older versions of Internet Explorer to render the transparent part of the graphic as
transparent rather than the white that can be seen in figure 28.
Figure 28 an image showing how Internet Explorer displayed a PNG background image before
a fix was implemented.
The header should look like it does in figure 29. This is how it looks in Mozilla Firefox.
Figure 29 an image showing how Mozilla Firefox displayed a PNG background image; this is
how the header should look.
There are a number of different hacks widely available on the Internet, some of which only
work for images and not background images, others work for both. Microsoft acknowledges
the problem in the previous versions of Internet explorer and offers their own hack to fix
this problem. The hack that Microsoft recommends involves using A CSS file. One problem
with this hack is that using it produces invalid CSS as some of the attributes that are being
used are only understood by versions of Internet Explorer the code can be seen in figure 30.
49
#header {
vertical-align: top;
text-align: left;
background-color: #<?php print $header_bg_colour; ?>;
background-image: url(http://www.digitally-
scarred.co.uk/dis/images/header/<?php print(date(n)); ?>.png);
background-position: right top;
background-repeat: no-repeat;
position: absolute;
top: 2.5%;
left: 5%;
right: 5%;
height: 20%;
width: 85%;
padding-left: 5%;
padding-top: 2%;
padding-bottom: 0%;
}
* html #header
{
background-image: none;
filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src="http://www.
digitally-scarred.co.uk/dis/images/header/<?php print(date(n)); ?>.png",
Figure 30 the CSS hack use to fix the transparency problem with Internet Explorer.
Unfortunately this hack does not allow for the positioning of the background image as it did
before so with the hack applied the header now looks like it does in figure 31 if sizingMethod
is set to crop. Figure 32 shows how the header is rendering if the sizingMethod is set to
scale and figure 33 show the how the header is rendered if the sizingMethod is set to
image.
Figure 31 an image showing a PNG background in Internet Explorer with sizingMethod set to
crop.
scale.
image
However it was not noticed until user testing that these hacks have subsequent effects on
other elements of the site that are on top of the image. The hack seems to turn anything placed
50
on top of the image in to part of the image, so for this site it turns the sign in form into an
image making it impossible to sign in to the website.
During development there was an issue with the time setting on the web server where the site
was being hosted. The problem was that the web server was actually situated in Berlin,
Germany so the time on the server is not GMT but GMT +1 Berlin. This could not be
changed so had to be taken into account during testing. The only way to solve this problem is
to switch the hosting of the site to a UK based server or get the server time set to GMT.
Another problem with the web hosting was found when it came to implementing the SSL to
ensure that information could not be read if intercepted. The problem was that the web
hosting coming where the site was being hosted did not support SSL so this could not be
used. However, as part of the Internet Services Administration (CS35910) module one of the
practicals involved setting up an apache web server with SSL, which allowed for a small
amount of experimentation with SSL and getting a page to be served in an encrypted state.
Figures 34 - 37 shows a simple page being served and the use of Ethereal ensuring the pages
contents were encrypted.
Figure 34 Screen shot showing the first message informing the user they are about to connect to
a secure webpage and asking whether they wish to accept the certificate from an unknown
authority.
51
Figure 35 Screen shot showing the web browser Informing the user they are about to enter a
secure website and asking the user if they wish to be informed when they are leaving the secure
part of the site.
Figure 36 Screen shot showing the page that has been sent in an encrypted state. The user can
tell the site is secure by the padlock in the bottom right hand corner of the browser window.
52
Figure 37 Screen shot showing Ethereal used to test that the web page was served in an
encrypted state.
53
10 Testing
10.1 Testing PHP applications
There are a number of different ways of testing PHP application, apart from the normal
manual testing. However a lot of the methods work better during development rather than
final testing of the site.
Some of the PHP Integrated Development Environments (IDEs) available have some form of
debugging and testing tools built into them.
Zend Studio (www.zend.com) is one rather expensive PHP IDE that allows for testing and
debugging to be run locally without any web server software being installed. During the
development of the project a trial version of the software was downloaded and used to debug
some of the pages of the site.
PHPUnit (www.phpunit.de) is an open source testing framework for testing PHP programs.
The writers of PHPUnit have written is so that it is very similar to JUnit the testing
framework for Java programs. PHPUnit requires installation on a web server. PHPUnit was
design to be used for Test Driven Development. Unfortunately PHPUnit was discovered too
late into the development to be used with this project.
Load testing is another form of testing that would be useful for a system such as this one.
Load testing involves ensuring that the servers and programming can handle the large
amounts of requests a system such as an online ticket booking system can generate.
10.2 Test Plan

The testing of this program will consist of manual testing, the test plan for which can be
found in Appendix A.
The site will be test for its level of accessibility using the WAI checklist to ensure all pages
meet the minimum standard decided for this website: WAI-AA.
User testing will also be done to comprehend the usability and accessibility of the website as
well as for gaining knowledge into how users actually will use the site and where they find
problems rather than relying on the development and manual testing finding these bugs.
10.3 Accessibility Testing

This testing is to ensure that the site conforms with the levels of the WAI standards that were
specified in the design. Three testing tables found in Appendix B are the three guideline
checklists drawn up by the W3C and available on their website [].
10.4 User Testing

User testing will test that the website is usable and simple to understand. This testing will
include getting a host of different users to complete some simple task on the website then
collect data on how quickly they are able to complete the tasks and their comments on what
they thought of the site. This test should be happening through development to ensure that the
site remains simple to use as development may make changes to the site that users do not like
or find difficult to use.
As suggested in PAS 87 Guide to good Practise in Commissioning Accessible Websites. the

test will include a wide range of possible users on the site including disabled users that
require some form of access technology to use a computer.
54
10.4.1 Client Side User Testing
Web Browser (include any access technology used, i.e. Screen Readers):
Age:
Level of computer competence between 1 10 (1 being complete novice and 10 being

expert):
How often do you use the Internet?
Do you buy products or services using the Internet (if yes please give examples)?
Test Testing User Comments

Number
UT1 Sign-up starting at the website homepage
locate the sign-up form and fill in details, and
register for site. (Please do not use real credit
card detail! All other information should be true.)
UT2 Verify Account Wait for email to be received
from the sign-up process and follow the link in
the email and verify your account
UT3 Login go to the websites homepage and
attempt to login.
UT4 Change Address Details locate the form and
change some element of your address details.
UT5 Change Credit Card Details locate the form and
change some element of your credit card details.
UT6 Change Password locate the form that allows
you to change your password and change your
password
UT7 Basic Search locate the basic search form
(available on every page) to do a search by band,
town and band & town.
Band The Streets
Town - London
Band/town Spunge/Aberystwyth
UT8 Advanced Search Using this form complete the
searching set out below.
Search 1:
Genre Hip Hop
City/Town: Birmingham
Search 2:
Venue Alexandra Palace
Date from 11th June 2006
Date to 21 June 2006
Search 3:
Artist - Steps
Venue The Playhouse - Erith
55
UT9 Locate a band using Genres List Using the

genre list find a bands information page.
UT10 Locate a band using Bands List using the band
list page find a bands information page
UT11 Make a Purchase choose a concert you have
found and go though the purchasing process
UT12 Log out finally log out the system
Any other comments on the site?
The results of the client side user testing can be seen in Appendix #.
10.4.2 Administration Side User Testing
Web Browser:
Age:

expert):
How often do you use the Internet?
Do you buy products services using the Internet?

Number
UT1 Login
UT2 Add a band Add three bands of your choice to
the database ensure you fill in all fields include
uploading a photograph. (note the tick box for
adding multiple bands.)
UT3 Edit a band Edit some element of the bands you
have just added details of
UT4 Delete a band Delete two bands from the band
list page.
UT5 Add a City/Town Add two cities or towns
ensuring you are not adding duplicate
cities/towns. (note the tick box for adding
multiple cities/towns.)
UT6 Add a venue Add two venues
UT7 Edit a venue edit the details of one of the
venues you added previously and confirm
changes where made.
UT8 Delete a venue delete one of the venues you
added previously.
UT9 Add a concert add three concerts of your
choice. (note the tick box for adding multiple
concerts.)
UT10 Edit a concert edit some detail of one
UT11 Delete a concert
UT12 Send Genre email -
56
UT13 Send Band Email -

UT14 Add Staff member
Any other comments:
57
10.5 Cross-Browser Compatibility Testing

This will be done to ensure that the website works and looks similar on a variety of different
browsers. The testing will be done on the most popular browsers which are:
Mozilla Firefox
Mozilla
Microsoft internet Explorer Version 6
Microsoft Internet Explorer Version 7
Opera
Safari
Netscape
IBM Home Page Reader version 3.04
Testing will also be done using JAWS for Window Version 7.0. JAWS is a screen reader
program produced by Freedom Scientific (www.freedomscientific.com). The software is
widely used within the blind and partially sighted community to allow people to access
computers using the JAWS software and a number of keyboard commands to navigate around
the screen.
The functioning of the website should be exactly the same as all of the programming is dealt
with at the server and not by the local browser. However because of long going browser wars
there can be dissimilarities between how the browsers interpret and render the HTML, and
CSS sent to them can differ.
The site also needs to be tested at different screen resolutions to ensure that the structure of
the site and positioning of the content does not change to much at different resolutions. The
site will be checked at the follow screen resolutions.
o 800 by 600
o 1024 by 768
o 1152 by 864
10.6 Testing Outcomes

10.6.1.1 Results of manual Testing
This section will comprise of screen shots of the website providing evidence that tests from
the manual test plan (Appendix A) have passed.
Test1 - 4
These test are to ensure that a staff user can add venues to the system and that the staff
member is returned to venue-form.php if there is a error with the data.
Figure 38 show venue-form.php filled in with the information set out in the test plan.
Figure 39 show the newly added venue in the list of venues.
Figure 40 show the user being told that a venue of already exists.
58
Figure 38
Figure 39
59
Figure 40
Figure 41
Tests 5-6
This ensures that a venues details can be edited
Figure 42 show the venue form with the capacity edited to 7000.
Figure 43 shows the venue list wit the data edited.
60
Figure 42
Figure 43
Tests 7-9
Testing that a venue can be deleted as long as there are no concerts scheduled for the select
venue.
Figure 44 shows the venue list with The Cinema in Aberystwyth and Alexandra Palace in
London selected for deletion.
Figure 45 show that only the Cinema in Aberystwyth has been deleted because there concert
scheduled there but Alexandra Palace has not been deleted because there are concerts
scheduled there.
61
Figure 44
Figure 45
Tests 10 13
This ensures that a band can be added and that any user errors are noticed and dealt with.
Figure 46 shows the band form with the band details set out in the test plan.
Figure 47 shows the client side band page where the details on the band are displayed.
Figure 48 shows the error displayed to the user if a required field is left null.
Figure 49 shows the error displayed to the user if they try to add a band that is already in the
database.
62
Figure 46
Figure 47
63
Figure 48
Figure 49
Tests 14 15
Ensuring that a bands details can be edited.
Figure 50 shows band form for the streets where the image and alternative text fields have
been edited
Figure 51 show the client side band info page for the streets after the edit has been the picture
and alt tag has been edited.
64
Figure 50
Figure 51
Test 16 18
Ensuring that a band can be deleted given the right circumstances.
Figure 52 show the band list page with Green Day and Madness selected for deletion.
Figure 53 shows that Green Day has been deleted but Madness has not been deleted as they
have a concert.
65
Figure 52
Figure 53
Test 19 21
Ensuring that a city or town can be added.
Figure 54 shows the city/town form with Bristol about to be added
Figure 55 shows the city/town form when a user try to add a town or city that is already
present in the database.
66
Figure 54
Figure 55
Tests 22 27
Ensuring that a concert can be added and that any user errors are dealt with.
Figure 56 show the concert form with data entered as set out in the test plan.
Figure 57 shows the concert in the concert list with the newly added concert.
Figure 58 shows the band form when the user has been return because a require field was left
null.
Figure 59 shows the band form when the user has been return because the band already have a
concert on the given date.
Figure 60 shows the band form when the user has been returned because the venue already as
a concert on the given date.
Figure 61 shows the band form when the user has been returned because the release date is
after the concert date.
67
Figure 56
Figure 57
68
Figure 58
Figure 59
69
Figure 60
Figure 61
Test 28 29
Ensuring that a concerts details can be edited.
Figure 62 shows the concert form with the number of tickets edited to 2000.
70
Figure 62
Test 30 33
Testing that concerts can be deleted.
Figure 63 show the concert list with The White Stripes concert at Alexandra Palace and the
Mitchell Brothers concert at The Warehouse selected for deletion.
Figure 64 shows that both of the concerts have been deleted.
Figure 65 show the email received by a client when the Mitchell Brothers concert was
deleted.
71
Figure 63
Test 35
Ensuring the variables used to store the database connection setting can be edited.
Figure 64 shows the database controller form.
Figure 64
72
Test 36
Ensuring that the CSS can be edited with out accessing the CSS file
Figure 65 shows the CSS controller page.
Figure 65
Test 37 42
Ensuring that emails can be sent to customers informing them of up coming events.
Figure 66 show the genre email form used to send emails to all customers of a particular
genre.
Figure 67 shows the email received by customers relating to the genre of Ska.
Figure 68 shows the band email form used to send emails to all customers of a particular
band.
Figure 69 shows the email received by customer relating to the band the Mitchell Brothers.
Figure 70 shows the birthday email form used to send out emails informing customers what
concerts are going on during their birthday month.
Figure 71 shows the mail received by customers with their birthday in June.
73
Figure 66
Figure 67
74
Figure 68
Figure 69
75
Figure 70
Figure 71
Tests 43 - 49
Ensuring that someone can signup to the site to become a registered user.
Figures 72 & 73 show a the signup form completed with the information in the test plan for
test number 43.
Figure 74 shows the page the user is sent to after submitting the form.
Figure 75 shows the email received by customers to allow them to validate their account.
Figure 76 shows the user validating their account.
Figure 77 shows the error the user is shown if the enter an incorrect user name and password
when logging in, or when a user attempts to login without validating their account.
76
Figure 72 - Showing a screen shot of the first part of the sign up form.
Figure 73 - Showing a screen shot of the second part of the sign up form.
77
Figure 74 Showing the page displayed after the user has successfully completed the sign up
form.
Figure 75 Showing the email the users receive to enable them to validate their account.
78
Figure 76 Showing the user validation form.
Figure 77 Showing the page the user is shown if they enter an incorrect user name and
password or their account has not been validated.
Test 50
Ensuring a customer can edit their address details.
Figure 78 shows form that allows users to edit their address details.
79
Figure 78- Screen shot showing the form for editing address details.
Test 51
Ensuring that a customer can edit their credit card details.
Figure 79 shows the form that allow users to edit their credit card details.
Figure 79 Screen shot showing the form for editing credit card details.
Test 52
Ensuring that a customer can change their password.
Figure 80 shows the form that allows user to enter their password.
80
Figure 80 Screen shot showing the form for changing passwords.
Tests 53 59
Ensuring the search facilities works correctly.
Figure 81 shows the results of a basic search for an artist call The Streets.
Figure 82 shows the results of a basic search for the town/city Aberystwyth.
Figure 83 shows the results of an advanced search for town/city London, Date from 11th
June 2006, Date to 24th June 2006.
Figure 81
81
Figure 82
Figure 83
Tests 60 64
Ensuring that tickets can be purchased.
Figure 84 show the band information page for The White Stripes.
Figure 85 shows the purchase page, informing the user which account the money for the
tickets will be taken from and a form to allowing the user to change the posting address.
Figure 86 shows the email received by the user to confirm the booking.
82
Figure 84 Screen shot show the band information band for The White Stripes.
Figure 85 Screen Shot Sh
Figure 86
83
10.6.1.2 Results of user testing

During the user testing phase it was discovered that the code that sends the clients the account
validation email sometimes did not work for some unknown reason and was not tripping the
test that ensured the emails were sent. Therefore the code was changed from the code in
figure # to the code in figure # which seems to be more reliable after more user testing.
private function client_varifacation_email($num)

{
$sql = "SELECT * FROM client WHERE clientNum = '".$num."';";
$result = mysql_query($sql);
$tuple = mysql_fetch_array($result, MYSQL_ASSOC);
$to = $tuple['email'];
$from = "mark@digitally-scarred.co.uk";
$headers ='From: dis@digitally-scarred.co.uk;';
$subject = "User Validation Email";
$content = "Dear ".$tuple['firstName']."\n\n".
"Thank you for registering with my tickets \n".
"before you can use the site you must validate your \n".
"account. to do so follow the link below. \n".
"www.digitally-scarred.co.uk/dis/validate.php?val=".$tuple['clientNum'].
"\n\n".
"Regards \n\n".
"The My Tickets Team";
$result = $this -> email_client($to, $from, $subject ,$content ,$headers);

if($result == false)
{
$this -> rollback(4, $num);
}
}
public function email_client($to, $from, $subject ,$content ,$headers)

{
$result = mail($to, $subject, $content);
return $result;
}
Figure 87 The first version of code that sent out client verification emails.
84
private function client_varifacation_email($num)

{
$sql = "SELECT * FROM client WHERE clientNum = '".$num."';";
$result = mysql_query($sql);
$tuple = mysql_fetch_array($result, MYSQL_ASSOC);
$to = $tuple['email'];
$from = "mark@digitally-scarred.co.uk";
$headers ='From: dis@digitally-scarred.co.uk;';
$subject = "User Validation Email";
$content = "Dear ".$tuple['firstName']."\n\n".
"Thank you for registering with my tickets \n".
"before you can use the site you must validate your \n".
"account. to do so follow the link below. \n".
"www.digitallyscarred.co.uk/dis/validate.php?val=".
$tuple['clientNum'].
"\n\n".
"Regards \n\n".
"The My Tickets Team";
$result = mail($to, $subject, $content, $headers);

if($result == false)
{
$this -> rollback(4, $num);
}
}
Figure 88 The second version of code that sent out client verification emails.
This problem could be a client side problem that the emails coming from the program are
being grey listed or filtered out by spam filters.
Some of the users pointed out that the layout of the genre tick boxes on the client form were a
little confusing so the margin around them was changed so they were spaced further apart.
The program requires emails be sent out regularly which is unfortunately limited by web
hosting company the amount of email that PHP scripts can send to this has caused a lot of
problems during testing. The people carrying out user testing did not receive validation emails
because to many people were signing up at the same time and the program tried to send all of
the email. Problems where also cause when trying to test the program that keep customers up
to date with event as testing took a lot of time waiting to be able to send email again. Figure #
show the conversation with the web hosting support desk when beliefs that the email problem
was being caused by the limiting implemented by them.
85
Figure 89
86
11 Critical Review
11.1 Methodology
The methodology chosen for the project worked rather well. However a more formal use of
test driven development would have aided with the implementation process. This would have
been considered more if PHPUnit had been discovered earlier into the implementation
process of project allowing for automated testing so that the development process is not
slowed down.
11.2 PHP
Because of the way PHP is designed to be used the mixing of markup and code can be
difficult to separate the two. I have managed to keep the two as separate as possible but there
are a few places where I feel with more time to refactor the code these problems could be
solved.
The Object Orientation of PHP allow for greater levels of abstraction between the different
technologies. It allows developers to separate code making it easier to be read. It also allows
developers to add extra functionality to a site without users of the site noticing.
My knowledge of the programming language and confidence programming it has grown

exponentially during the course of this project and during development I discovered a lot of
functions that I did not know about, there were a number of functions that had no place for in
this project but hopefully I will get a chance to experiment with tem very soon.
11.3 CSS
CSS layout required a large amount of research and experimentation, but overall it was well
worth the effort, as CSS layout allows the programmer much more control of the site layout
than tables do, such as overlapping of elements. A lot of the problems with using CSS layout
are due to the different ways that web browsers interact with the code
. This make developing a site using CSS layout an interesting process fiddling with different
settings until the page looks right in all web browsers.
The use of PHP within the CSS file is a very nice way of allowing a user with no web
development experience to change the look of their site quickly and with little fuss.
11.4 Security
My knowledge of Internet security issues has greatly improved since start this project. Before
I started this project I had a very limited knowledge the issues that were involved with
ensuring the security of a websites, my knowledge was limited to know of SQL injection and
Phishing.
I found the research and implementation of security feature the most stimulating throughout
the project and plan on furthering my knowledge in this field as well as web server security.
I feel the security of the site is quite strong however it is no where near completely secure. I
would have liked to have been able to implement the project using Secure Socket Layers.
87
11.5 Accessibility
The project is missing a non-visual CAPTCHA, this would be one of the main things that
should be added to ensure the client side of the site was deemed accessible. Unfortunately
there was not time to add a non-visual CAPTCHA.
This project has increased my experience with creating accessible web pages and has
understanding of web accessibility and how different users interact with that same website.
It would have been nice to be able to user testing with partially sighted and blind users to get
some insight into how they navigate a site and what they find annoying to improve my
understanding of how to make future work as accessible as possible.
11.6 Testing
The testing of PHP programs is a very difficult process. It was found that user testing found
more errors than the traditional manual testing done by the developers. If the project was to be
started again the methodologies used would include formal Test Driven Development using a
test framework such as PHPUnit. The testing would also include user testing upon reaching
major milestones throughout development.
Another problem the user testing highlight was how difficult it is to replicate errors that
occurred while the user was going though their testing. It was felt that the best way to carry
out user testing was on a one to one basis so that the developer could record what the user
does to assist in identifying where problems occur and how they can be fixed.
Unfortunately there were no users with visual disabilities which would have been very useful
for testing how accessible the website is rather than just relying on checking the site against
the WAI checklist and using online testing programs. It was also discovered that use of the
access software IBM homepage reader and JAWS for window required a lot of user expertise
and also had a steep learning curve even for completing the most basic of tasks. This meant
that the browser testing with these pieces of software was very limited
Security Testing could not be carried out on the program as testing much of the security of
such a program requires knowledge of hacking practises that were not available. Large
companies that implement systems like this that do require security testing hire White Hat
Hackers (hackers who use their skill for good ) to test how secure their program is.
11.7 Improvements
There are a few ways that it is felt the system could be improved with more time or in a
second version. These improvements include;
A calendar of events allowing users to browse all the events in a given month quickly. This
feature has been added to some of the existing online ticket sales systems during the
implementation of this project.
It would have been nice to have been able to have the system to connect an online payment
solution.
I would learn how to set up a web server properly so that I had more control over the features
and technology I would have at my disposal. Having a dedicated server would have sped up
the implementation stage of the project and allow me to implement feature that such as SSL
and database transactions that would have been implemented had the chance to use them been
there.
88
The CSS controller page could be improved by implementing a colour picker so that I was not
left to the user to work out the hexadecimal value of the colour they want.
The problem with the header image could have been solved by using PHP to dynamically
create the image when the month changed or the background colour of the header was
changed using CSS controller page.
11.8 Overall
Using a web hosting service can be very restrictive as much of this document shows. A large
percentage of problems occurring during development were caused by the web hosting
service not supporting a technology or settings under the control of the web hosting company.
The only way of guaranteeing that a program can make use of any functionality that a system
will require not to use a web hosting service, but instead set up a web server dedicated to
running any programmes written. This allows program developers to install or allow use of
any functionality they require for their program to work. Another advantage of not using a
web hosting service is the program could have been made more portable if it was originally
written on a dedicated server. However, running your own web server for such a site as this
requires a lot of knowledge on keeping a server freely available to the public secure.
This has prompted my to put more effort in to learn how to setup and administer a web server
for any future work to ensure that programs are not compromised by what the web hosting
company do and do not offer.
The project has introduced me to a number of aspects for programming for the Internet
including: how to write program so that it is as secure as possible. I found the research about
the security issues and how to protect a website very interesting. My only regrets about the
security of the site was not being able to use SSL and I wish I had researched more security
issues before starting coding as this would have saved a lot of time.
89
12 Bibliography
[1] British Standards Institute, 2005, PAS 78 Guide to Good Practice in Commissioning
Accessible Websites
[2] H. M. Deitel, P. J. Deitel & Tem. R. Nieto, 2002, Internet & World Wide Web How to
Program, Pearson Education Prentice Hall, United States of America
[3] Elizabeth Castro, 2003, HTML for the World Wide Web with XHTML and CSS,
Peachpit Press, United States of America
[4] Wendy Chisholm, Gregg Vanderheiden & Ian Jacobs, 1999, Web Content
Accessibility Guildlines 1.0, http://www.w3.org/TR/WAI-WEBCONTENT/ (Date Accessed:
14/02/06)
[5] Wendy Chisholm, Gregg Vanderheiden & Ian Jacobs, 1199, Checklist of Checkpoints
for Web Content Accessibility Guidelines 1.0, http://www.w3.org/TR/WAI-
WEBCONTENT/full-checklist.html (Date Accessed: 14/02/06)
[6] Christine Faulkner 1998, The Essence of Human-Computer Interaction, Prentice Hall,
England
[7] Disability Discrimination act , 1995, Disability Discrimination act,

http://www.opsi.gov.uk/acts/acts1995/1995050.htm (Date accessed: 07/03/06)
[8] Jeremiah Grossman WhiteHat Security, (2001), Web Application Security,

http://www.whitehatsec.com/presentations/Black_Hat_Europe_2001/Black_Hat_Europe2001
_Presentation.ppt (Date Accessed: 02/04/06)
9] Jeremiah Grossman WASC (Web Application Security Consortium), 2004, WASC

Activities and U.S. Web Application Security Trends,
http://www.whitehatsec.com/presentations/WASC_WASF_1.02.pdf (Date Accessed:
02/04/06)
10] Matt May - W3C, 2005, Inaccessibility of CAPTCHA

http://www.w3.org/TR/turingtest/ (Date Access: 21/03/06)
[11] Eric A Meyer, 2004, Cascading Style Sheets The Definitive Guide, OReilly Media,
United States of America
[12] Jakob Nielsen, 2000, Designing Web Usability: The Practice of Simplicity, 2000,
New Riders Publishing, United States of America
[13] Christopher Schmitt, 2004, CSS cookbook, OReilly Media, United States of America
[14] Chris Snyder and Micheal Southwell, 2005, Pro PHP Security, Apress, United States
of America
[15] Janet Valade, 2002, PHP & MySQL for Dummies, Wiley Publishing Inc, Canada
[16] Luke Welling and Laura Thomson, 2005, PHP and MySQL Web Development, Sams
Publishing, United States of America
90
[17] Matt Zandstra, 2004, PHP 5 Objects, Patterns, and Practise, Apress, United States of
America
91
13 Appendix A Manual Testing Test plan

Test Functional Testing Expected Actual Outcome
Number Requirement Outcome
1 FR5 A venue can be A staff user Test Passed
added to the system should be able to Staff users are
Venue Name Art add information able to add
Centre about a concert venues to the
Town/City venue into the system
Aberystwyth system.
Capacity 2500
2 FR5 Only administrators Only staff set as Test Passed

and data entry staff administrators only
can add venues and data entry administrators
staff should be and data entry
able to gain staff can add
access to add venues.
venues.
3 FR5, FR6 When a venue is If a staff user Tested Passed
added all required tries to add a if some of the
fields are filled in. venue and leaves required fields
a require field are left blank the
blank they are venue is not
returned to the added and the
concert form and staff user is
informed of the informed so.
error.
4 FR5, FR6 When a venue is If a staff user Test Passed a
added there are no tries to add a venue with the
other venues with venue they same name and
the same name in should not be town/city as a
the same city or able to add a venue in the
town venue with the database cannot
same name and be added.
town or city if
they do they are
returned to the
concert form and
informed of the
error.
5 FR6 That a venue A staff user Test Passed
information can be should be able to Venue
updated update information can
information about be edited.
a concert venue
that exists in the
system.
6 FR6 Only administrators Only staff set as Test passed
and data entry staff administrators only
can edit venues and data entry administrators
able to gain staff can edit
92
access to edit venues

venues.
7 FR6 A venue can be A staff user Test Passed
removed should be able to Venues can be
remove a concert deleted.
venue from the
system.
8 FR6 A venue can not be A venue should Test Passed A
removed if there is not be deleted if venue is not
a concert scheduled there is a concerts deleted if there is
there. scheduled in the a concert
venues scheduled there.
9 FR6 Only administrators Only staff set as Test passed -
and data entry staff administrators Only
can delete venues and data entry administrators
able to gain staff can delete
access to delete venues
venues.
10 FR5 A band can be A staff/admin Test Passed A
added. user should be band can be
Name The Streets able to add added to the
Genre Hip Hop information about database.
Website www.the- a band to the
streets.co.uk system.
Description -
Picture -
11 FR5 Only administrators Only staff set as Test passed -
can add bands and data entry administrators
access to add bands
bands.
12 FR5, FR6 All require fields If a staff user Test Passed - All
must be completed tries to add a require fields
for a band to be band and leaves a must be
added required field completed for a
blank they are band to be added
returned to the if they are not
concert form and the user is sent
informed of the back to the form
error. and informed of
the error.
13 FR5, FR6 A band cannot be If a staff user Test Passed A
added with the tries to add a band cannot be
same name as band with the added if there is
another band. same name as a band in the
another band they database with the
are returned to same name.
the concert form
and informed of
the error.
14 FR6 A bands A staff user Test Passed - A
93
information can be should be able to bands

updated update a bands information can
information that be updated
exists on the
system.
15 FR6 Only administrators Only staff set as Test Passed -
can edit bands and data entry administrators
access to edit bands
bands.
16 FR6 A band can be A staff user Test Passed a
removed should be able to band can be
remove a band deleted.
from the system.
17 FR6 A band will not be A band should Test Passed - A
removed if they not be deleted if band will not be
have a concert the band has removed if they
scheduled concerts have a concert
scheduled. scheduled
can delete bands and data entry administrators
able to gain staff can delete
access to delete bands
bands.
19 FR5 A city / town can A staff user Test Passed a
be added. should be able to city/town can be
City/town: Bristol add information added.
about a town or a
city into the
system.
20 FR5 When a city / town If a staff user Test Passed all
is added all require tries to add a city required fields
fields have been / town and leaves must be filled in
filled in a required field before the data is
blank they are added to the
returned to the database.
concert form and
informed of the
error.
21 FR5 A city / town If a staff user Test Passed a
cannot be added tries to add a city town or city can
twice with the same not be added
name as another twice.
city they are
returned to the
concert form and
informed of the
error.
22 FR5 A concert can be A staff user Test Passed A
added should be able to concert can be
94
Band: Feeder add information added.

Venue: Arts Centre about a concert
Aberystwyth into the system.
Time: 18:30:00
Date: 21 January
2007
Number of Tickets:
13000
Ticket price: 16.80
Release Time:
09:00:00
Release Date: 15
June 2006
can add concerts and data entry administrators
access to add concerts
concerts.
24 FR5, FR6 All required fields If a staff user All require fields
must be completed tries to add a must be
for a concert to be concert and completed for a
added leaves a required concert to be
field blank they added or user
are returned to will be returned
the concert form to concert form
and informed of and informed of
the error. the error.
25 FR6, FR6 A concert venue If a staff user Test Passed A
cannot have two tries to add a concert cannot
concerts booked on concert for a be added if there
the same date. venue when one is already a
is already booked booking for that
for that date they venue on that
are returned to day.
the concert form
and informed of
the error.
26 FR5, FR6 A band cannot have If a staff user Test Passed a
two concerts tries to add a concert can not
booked on the same concert for a be added if the
day. band when one band already
is already booked have a concert
for that date they on the given day.
are returned to
the concert form
and informed of
the error.
27 FR5, FR6 The concert date If a staff user Test Passed if
cannot be after the tries to add a the release date
release date for the concert with the is after the
tickets ticket release date concert date the
set after the concert will not
95
concert date they be added and the

are returned to user will
the concert form returned to the
and informed of concert form and
the error. informed of the
error.
28 FR6 That a concerts A staff user Test Passed A
information can be should be able to concert can be
updated update updated.
information about
a concert that
exists in the
system.
can edit concerts and data entry administrators
access to edit concerts
concerts.
30 FR6 That a concerts A staff user Test Passed A
information can be should be able to concert can be
deleted delete concert deleted.
that exists in the
system.
31 FR6 Only administrators Only staff set as
and data entry staff administrators
can edit concerts and data entry
staff should be
able to gain
access to delete
concerts.
32 FR6 That if a concert When a concert is Test passed if a
has been released delete clients are concert is
and it is deleted informed of its cancelled clients
client with tickets cancellation are email when it
booked are sent an is deleted.
email
33 FR6 Test that when When a concert is Test Passed
concert with delete any When a concert
bookings is deleted booking that is delete any
the bookings are were made for it booking for that
deleted too. should be deleted concert are also
to keep deleted.
referential
integrity
34 Staff cannot buy A user logged in Test Passed A
tickets. as staff should member of staff
not be able to buy could not access
tickets. the pages that
allow clients to
purchase tickets
35 FR10 Database settings An administrator Test Passed
can be edited should be able to Administrators
96
change database can change

connection database settings
settings from the and this can only
websites be done by
Administrators
36 FR10 That style settings A administrator Test Passed -
can be changed should be able to Administrators
change style can change style
settings from the settings and this
websites can only be done
by
Administrators
37 FR7 That an email can Staff should be Test Passed
be sent out able to send out Staff can send
updating fans of a emails to fans of out emails to
particular genre a particular fans of a
genre. particular genre
38 FR7 That genre update Only fans of a Test Passed
emails only got to particular genre Only fans of a
fans of the selected should receive genre receive
genre. genre update update emails for
emails that genre.
39 FR7 That an email can Staff should be Test Passed
be sent out able to send out Staff can send
regarding a selected emails updating out email with
band. people of a information
bands concerts. about a bands
concerts.
40 FR7 That a client only Client should Test Passed
receives an emails only receive Clients only
when they have emails about receive emails
shown an interest bands within the about bands
in the genre of genres they within the genre
which the band is selected when they registered
in. they signed up. an interest in.
41 FR7 Test that staff can Staff can send out Test Passed
send out birthday emails about a staff can send
emails. months events out birthday
and all clients emails.
with birthdays in
that month
receive the email.
42 FR7 That only clients Only clients with Test Passed
with birthdays in birthdays in the only clients with
the selected month selected month birthdays within
receive a birthday should receive an the selected
email. email. month receive
birthday emails.
43 FR2 Test that it is Upon completion Test passed
possible for non- of the client form users are able to
members of the site the user should sign up for the
to sign up to be registered with site using the
become a member. the site. client form.
First Name Mark
97
Surname Bradley
Email Address
mdb2@aber.ac.uk
Date of Birth 11
June 1984
Address Line 1
108D
Address Line 2
Pentre Jane Morgan
Town
Aberystwyth
County
Ceredigion
Postcode SY23
3TG
Telephone Number
01322441848
User Name mdb2
Password
password
Genres Brit pop,
Hip Hop, Indie,
Ska, Rock and Roll
Card Type: Card B
Card Number
0123987456
Start Date: 07/2003
Expiry Date:
10/2008
Security Code 951
44 FR2 All required fields If a user leaves a
must be filled in required field
blank they should
be sent back to
the client form
and informed of
the error.
45 FR2, FR4 Test that a client is The client should Tested Passed
not able to sign up not be allowed to If a user enters
with out entering sign up to the site an incorrect
the correct without entering CAPTCHA
CAPTCHA string. the correct string they are
CAPTCHA returned to the
string. client form and
informed of the
error.
46 FR2 Test that a client is The client should
not able to sign up not be able to
without the sign up in the site
password in the if the both
password and re- passwords do not
enter password match.
fields matching.
47 FR3 Once someone has Once a client Test Passed
98
registered to registers with the Users receive a

become a member site a validation validation email
they are sent a email should be upon completing
customer validation sent to their given the signing up
email email address process
that will send
them a link to
validation page
48 FR3 A customer is The link on the Test Passed
validated upon validation email The email
following the link will link to the includes a link
to validation page. validation page that allows the
with the clients user to validate
clientNum their account
being used to
uniquely identify
the user.
49 FR3 A customer is Before the user Test Passed a
unable to log in to validates their user is not able
their account until account they to log in without
they have validated should not be their account
their account able to log in to being verified.
the website.
Once they have
registered they
should be able to
log in to the site.
50 FR9 That a client user A client should Test passed
can edit their be able to edit Users are able to
address details once their address change their
they have signed in. details once they address details
have logged into once they have
the website. logged into the
site.
41 FR9 That a client user A client should Test Passed -
can edit their credit be able to edit Users are able to
card details once their credit card change their
they have signed in. details once they credit card
have logged into details once they
the website. have logged into
the site.
52 FR9 That a client user A client should Test Passed -
can change their be able to edit Users are able to
password once they their password change their
have signed in. once they have password once
logged into the they have logged
website. into the site.
53 FR8 Test that the basic The user should Test Passed
search works when be shown all of The user was
searching for an the concerts for shown a list of
artist returns the band entered all concerts for
correct results. in the test box the band entered
in the text box.
54 FR8 Test that the basic The user should Test Passed the
99
Search for a city be shown all of user was shown

returns correct the concerts in a list of all
results. the town selected concerts in the
in the drop down selected city.
menu.
55 FR8 Test that the basic The user should Test Passed
search for an artist be shown all of The user is
and a city returns the concerts in shown a list of
the correct results. the town selected the concerts in
in the drop down the selected city
menu where the where the band
band playing is playing is the
that in the text one entered in
box. the text box.
56 FR8 Test that the To stop Test Passed the
advanced search conflicting search artist and genre
returns the correct parameters a search works and
results when search can only brings back the
searching by artist be done on ether correct results.
or genre the artist or the
genre so if the
artist is set that
will override the
genre selection.
57 FR8 Test that the To stop Test Passed
advanced search conflicting search The city/town
returns the correct parameters a and venues
results when search can only search works and
searching by be done on ether brings back the
city/town or venue the artist or the correct results
city/town or
venue if the
venue it will
always override
the city/town
selection
58 FR8 Test that the The date search Test Passed
advanced search allows to search The date search
returns the correct for concerts on a works correctly
results when given date or for and bring back
searching by a date concert in- the correct
or set of dates. between a set of results.
dates.
59 FR8 Test that if a search If a search returns Test Passed if
yields no results the not results rather a search finds no
user is informed so than leaving the results the user is
and not just shown page blank the informed so.
a blank page. search should be
informed that
their search
found no concerts
60 FR1 Test that a buy When tickets are Test Passed if
tickets link will not sold out and there are tickets
only appear if release clients available clients
100
tickets are available should be able to are able to

follow a link to purchase them.
tickets.php to
start the
purchasing
process.
61 FR1 Test that if tickets If tickets are sold Test Passed - If
are sold out the out client should tickets are sold
client is informed not be able to out the link to
so. purchase tickets tickets.php is
read with plain
text saying sold
out.
62 FR1 Test that if tickets Client should not Test Passed
have not been be able to buy there is no link
released yet the ticket that have for concert
client is informed not yet been tickets until the
so released tickets are
released.
93 FR1 Test that the On purchase.php Test Passed
program totals up the client should The program
the price and be told the total works out the
informs the client price of there correct total for
of the total and the purchase the purchase
account the money
will be taken from
64 FR12 WAI Level A Web pages Test Passed
compliance should pass the See appendix #
WAI level A for completed
checklist checklist
requirements,
65 FR12 WAI Level AA Web pages Test Passed
Compliance should pass the See appendix #
WAI level AA for completed
checklist checklist
requirements
101
14 Appendix B - results of user testing

Web Browser (includes any access technology used, i.e. Screen Readers):
IE 7 and Mozilla 1,5
Age: 44

expert): 8
How often do you use the Internet? 2 hrs/day
Do you buy products or services using theInternet (if yes please give examples)? Yes EBay,
suppliers (DABS, etc,) Flights, hotels, car hire!

Number
UT1 Sign-up starting at the website homepage Took about 2 mins to sign
locate the sign-up form and fill in details, and up.
UT2 Verify Account Wait for email to be received email did not arrive!
from the sign-up process and follow the link in
the email and verify your account
UT3 Login go to the websites homepage and Done
attempt to login.
UT4 Change Address Details locate the form and Done, but no confirmation
change some element of your address details. that the change has been
accepted
UT5 Change Credit Card Details locate the form and Done, but no confirmation
change some element of your credit card details. that the change has been
accepted
UT6 Change Password locate the form that allows Done, but no confirmation
you to change your password and change your that the change has been
password accepted
UT7 Basic Search locate the basic search form 2006/-7/11 No option to
(available on every page) to do a search by band, change the date format?
town and band & town. Most brits use 11/7/2006
Band The Streets
Town - London
UT8 Advanced Search Using this form complete the Mitchell Brothers
searching set out below. The Streets
Search 1:
Genre Hip Hop
City/Town: Birmingham
Search 2:
Search 3:
102
Artist - Steps
UT9 Locate a band using Genres List Using the OK worked (Artic Monkeys)
UT10 Locate a band using Bands List using the band OK worked (Artic Monkeys)
UT11 Make a Purchase choose a concert you have Tried to buy tickets for the
found and go though the purchasing process killers, dumped back to main
screen
UT12 Log out finally log out the system
103
Internet Explorer 6
Age: 51

expert): 6
How often do you use the Internet? Most working days
Do you buy products or services using the Internet (if yes please give examples)? Yes,
Tickets and Some Electrical products

Number
UT1 Sign-up starting at the website homepage Ok
locate the sign-up form and fill in details, and Easy to follow instructions
UT2 Verify Account Wait for email to be received OK
from the sign-up process and follow the link in e-mail sent back almost
the email and verify your account immediately
UT3 Login go to the websites homepage and OK entered site immediately
attempt to login.
UT4 Change Address Details locate the form and Changed telephone number
change some element of your address details. details, easy to do
UT5 Change Credit Card Details locate the form and Changed type of card, easy
change some element of your credit card details. to do
UT6 Change Password locate the form that allows Changed password. Eay to
you to change your password and change your follow instructions
password
UT7 Basic Search locate the basic search form OK, easy to follow
(available on every page) to do a search by band, instructions
Band The Streets
Town - London
UT8 Advanced Search Using this form complete the Easy to follow instructions
searching set out below. Results were Street or
Search 1: Mitchell Bros. The 2nd
Genre Hip Hop search produced no results,
City/Town: Birmingham assume this was correct. The
3rd search also produced no
Search 2: results, I wonder why?
Search 3:
Artist - Steps
UT9 Locate a band using Genres List Using the Used this to locate Ska,
genre list find a bands information page. Madness got details of band
104
on screen
UT10 Locate a band using Bands List using the band Used list, to locate Red Hot
list page find a bands information page Chilly Peppers
UT11 Make a Purchase choose a concert you have Made a purchase for
found and go though the purchasing process Madness tickets.
UT12 Log out finally log out the system Logged Out
Thought this was an easy to use site.
The dates all seem to be in reverse.

Year/Month/Day this could be confusing most are set up Day/Month/Year
105
Internet Explore 6
Age: 23

expert): 6
How often do you use the Internet? daily
Do you buy products or services using the Internet (if yes please give examples)? Yes
play.com, amazon.

Number
UT1 Sign-up starting at the website homepage ok
locate the sign-up form and fill in details, and
UT2 Verify Account Wait for email to be received The link that you get sent
from the sign-up process and follow the link in inst one you can click on you
the email and verify your account have to cut and paste it
UT3 Login go to the websites homepage and ok
attempt to login.
UT4 Change Address Details locate the form and Changed, but wouldnt it be
change some element of your address details. good if once you clicked on
change it said changes have
been successful?
UT5 Change Credit Card Details locate the form and Same as above, casue you
change some element of your credit card details. dont know if its changed it
UT6 Change Password locate the form that allows
you to change your password and change your
password
UT7 Basic Search locate the basic search form Dont like the date format
(available on every page) to do a search by band,
Band The Streets
Town - London
UT8 Advanced Search Using this form complete the Fine
searching set out below.
Search 1:
Genre Hip Hop Wouldnt the venues be
City/Town: Birmingham better in alphabetical order?
Search 2:
Search 3:
Artist - Steps
106
UT9 Locate a band using Genres List Using the ok

UT10 Locate a band using Bands List using the band ok
UT11 Make a Purchase choose a concert you have ok
found and go though the purchasing process
UT12 Log out finally log out the system ok
107
15 Appendix C - WAI
The three tables below are the WAI checklists for ensuring your site is accessible take from []
15.1.1.1.1 Priority 1 checkpoints

In General (Priority 1) Yes No N/A
1.1 Provide a text equivalent for every non-text element (e.g., via "alt",
"longdesc", or in element content). This includes: images, graphical
representations of text (including symbols), image map regions, animations
(e.g., animated GIFs), applets and programmatic objects, ascii art, frames, 9
scripts, images used as list bullets, spacers, graphical buttons, sounds (played
with or without user interaction), stand-alone audio files, audio tracks of video,
and video.
2.1 Ensure that all information conveyed with color is also available without
9
color, for example from context or markup.
4.1 Clearly identify changes in the natural language of a document's text and
9
any text equivalents (e.g., captions).
6.1 Organize documents so they may be read without style sheets. For example,
when an HTML document is rendered without associated style sheets, it must 9
still be possible to read the document.
6.2 Ensure that equivalents for dynamic content are updated when the dynamic
9
content changes.
7.1 Until user agents allow users to control flickering, avoid causing the screen
9
to flicker.
14.1 Use the clearest and simplest language appropriate for a site's content. 9
And if you use images and image maps (Priority 1) Yes No N/A
1.2 Provide redundant text links for each active region of a server-side image
9
map.
9.1 Provide client-side image maps instead of server-side image maps except
9
where the regions cannot be defined with an available geometric shape.
And if you use tables (Priority 1) Yes No N/A
5.1 For data tables, identify row and column headers. 9
5.2 For data tables that have two or more logical levels of row or column
9
headers, use markup to associate data cells and header cells.
And if you use frames (Priority 1) Yes No N/A
12.1 Title each frame to facilitate frame identification and navigation. 9
And if you use applets and scripts (Priority 1) Yes No N/A
6.3 Ensure that pages are usable when scripts, applets, or other programmatic
objects are turned off or not supported. If this is not possible, provide 9
equivalent information on an alternative accessible page.
And if you use multimedia (Priority 1) Yes No N/A
1.3 Until user agents can automatically read aloud the text equivalent of a
visual track, provide an auditory description of the important information of the 9
visual track of a multimedia presentation.
1.4 For any time-based multimedia presentation (e.g., a movie or animation),
9
synchronize equivalent alternatives (e.g., captions or auditory descriptions of
108
the visual track) with the presentation.

And if all else fails (Priority 1) Yes No N/A
11.4 If, after best efforts, you cannot create an accessible page, provide a link to
an alternative page that uses W3C technologies, is accessible, has equivalent
9
information (or functionality), and is updated as often as the inaccessible
(original) page.

2.2 Ensure that foreground and background color combinations provide
sufficient contrast when viewed by someone having color deficits or when 9
viewed on a black and white screen. [Priority 2 for images, Priority 3 for text].
3.1 When an appropriate markup language exists, use markup rather than
images to convey information.
3.2 Create documents that validate to published formal grammars. 9
3.3 Use style sheets to control layout and presentation. 9
3.4 Use relative rather than absolute units in markup language attribute values
9
and style sheet property values.
3.5 Use header elements to convey document structure and use them according
to specification.
3.6 Mark up lists and list items properly. 9
3.7 Mark up quotations. Do not use quotation markup for formatting effects
9
such as indentation.
6.5 Ensure that dynamic content is accessible or provide an alternative
9
presentation or page.
7.2 Until user agents allow users to control blinking, avoid causing content to
9
blink (i.e., change presentation at a regular rate, such as turning on and off).
7.4 Until user agents provide the ability to stop the refresh, do not create
9
periodically auto-refreshing pages.
7.5 Until user agents provide the ability to stop auto-redirect, do not use
markup to redirect pages automatically. Instead, configure the server to perform 9
redirects.
10.1 Until user agents allow users to turn off spawned windows, do not cause
pop-ups or other windows to appear and do not change the current window 9
without informing the user.
11.1 Use W3C technologies when they are available and appropriate for a task
9
and use the latest versions when supported.
11.2 Avoid deprecated features of W3C technologies. 9
12.3 Divide large blocks of information into more manageable groups where
9
natural and appropriate.
13.1 Clearly identify the target of each link.
13.2 Provide metadata to add semantic information to pages and sites. 9
13.3 Provide information about the general layout of a site (e.g., a site map or
table of contents).
13.4 Use navigation mechanisms in a consistent manner. 9
109

5.3 Do not use tables for layout unless the table makes sense when linearized.
Otherwise, if the table does not make sense, provide an alternative equivalent 9
(which may be a linearized version).
5.4 If a table is used for layout, do not use any structural markup for the
9
purpose of visual formatting.
And if you use frames (Priority 2) Yes No N/A
12.2 Describe the purpose of frames and how frames relate to each other if it is
9
not obvious by frame titles alone.
And if you use forms (Priority 2) Yes No N/A
10.2 Until user agents support explicit associations between labels and form
controls, for all form controls with implicitly associated labels, ensure that the 9
label is properly positioned.
12.4 Associate labels explicitly with their controls. 9
And if you use applets and scripts (Priority 2) Yes No N/A
6.4 For scripts and applets, ensure that event handlers are input device-
9
independent.
7.3 Until user agents allow users to freeze moving content, avoid movement in
9
pages.
8.1 Make programmatic elements such as scripts and applets directly accessible
or compatible with assistive technologies [Priority 1 if functionality is 9
important and not presented elsewhere, otherwise Priority 2.]
9.2 Ensure that any element that has its own interface can be operated in a
9
device-independent manner.
9.3 For scripts, specify logical event handlers rather than device-dependent
9
event handlers.

4.2 Specify the expansion of each abbreviation or acronym in a document
9
where it first occurs.
4.3 Identify the primary natural language of a document. 9
9.4 Create a logical tab order through links, form controls, and objects.
9.5 Provide keyboard shortcuts to important links (including those in client-side
9
image maps), form controls, and groups of form controls.
10.5 Until user agents (including assistive technologies) render adjacent links
distinctly, include non-link, printable characters (surrounded by spaces) 9
between adjacent links.
11.3 Provide information so that users may receive documents according to
their preferences (e.g., language, content type, etc.)
13.5 Provide navigation bars to highlight and give access to the navigation
9
mechanism.
13.6 Group related links, identify the group (for user agents), and, until user
9
agents do so, provide a way to bypass the group.
13.7 If search functions are provided, enable different types of searches for 9
110
different skill levels and preferences.

13.8 Place distinguishing information at the beginning of headings, paragraphs,
9
lists, etc.
13.9 Provide information about document collections (i.e., documents
9
comprising multiple pages.).
13.10 Provide a means to skip over multi-line ASCII art. 9
14.2 Supplement text with graphic or auditory presentations where they will
9
facilitate comprehension of the page.
14.3 Create a style of presentation that is consistent across pages. 9
And if you use images and image maps (Priority 3) Yes No N/A
1.5 Until user agents render text equivalents for client-side image map links,
9
provide redundant text links for each active region of a client-side image map.
5.5 Provide summaries for tables. 9
5.6 Provide abbreviations for header labels. 9
10.3 Until user agents (including assistive technologies) render side-by-side
text correctly, provide a linear text alternative (on the current page or some 9
other) for all tables that lay out text in parallel, word-wrapped columns.
And if you use forms (Priority 3) Yes No N/A
10.4 Until user agents handle empty controls correctly, include default, place-
9
holding characters in edit boxes and text areas.
111

Online Ticket Booking System: CS39010 Dissertation

Uploaded by

Copyright:

Available Formats

You might also like

Online Ticket Booking System: CS39010 Dissertation

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Online Ticket Booking System: CS39010 Dissertation

Uploaded by

Copyright:

Available Formats

Mark Bradley (mdb2) Dissertation CS39030

Online Ticket Sales System

Online Ticket Booking System

Author: Mark Bradley

Name: Mark Bradley

The website will allows be design with accessibility in mind.

The website produced by this project can be found at:

Figure 1 Screen shot of the Ticket Master website.

Figure 2 Screen Shot of the Aloud website.

Figure 3 A screen shot of the Ticket Web website.

8.1 Use Case Diagrams

Figure 4 The User Case Diagram

8.2 Functional Requirements

FR1 Allow all registered users to purchase tickets for concerts.

8.3 Extra Functionality

8.4.1 Structured Query Language (SQL) Injection

8.4.1.1 Preventing SQL Injection

8.4.2 Cross Site Scripting (XSS)

8.4.2.1 Preventing XSS

8.4.3 Session Hijacking

8.4.3.1 Listening to network traffic

8.4.3.2 Phishing, forwarding and proxies

Figure 5 an example Phishing URL.

8.4.3.3 Session Fixation

Figure 6 An example URL used for session fixation.

8.4.3.4 Preventing Session Hijacking

8.4.3.4.1 Secure Socket Layer (SSL)

8.4.3.4.2 Disabling the use of session IDs as $_GET Variables

8.4.3.4.3 Session Timeout

8.4.3.4.4 Regenerating Session IDs

8.4.4 Password Encryption

8.4.5 Secure Socket Layer (SSL)

8.4.6 Allowing only human users

8.4.6.1 Text Image CAPTCHAs

8.4.6.2 Cognitive CAPTCHAs

Figure 7 a selection of images that could be used as a cognitive CAPTCHA.

Figure 8 a picture of a clown that could be used as a Cognitive CAPTCHA

8.4.6.3 Audio CAPTCHAs

An example of an audio CAPTCHA is used for the hotmail signup process

8.4.6.4 CAPTCHA Accessibility and usability

8.4.7 Verifying your users

8.4.8 Maintaining a secure environment

8.4.9 Security Functionality

8.5 Web Accessibility and Usability

The British Standard Institute defines accessibility of websites as

Jakob Nielsen has a view on web accessibility that:

8.5.1 Web Usability

8.5.2 Accessibility Law

Disability Discrimination act 1995 Part III section 19.

8.5.3 Online Testing

8.5.4 Web Content Accessibility Guidelines 1.0 (WCAG 1.0)

8.5.5 Publicly Available Specification 78: Guide to good Practise in

8.6 Online Finance Systems

8.6.1 PayPal and WorldPay

8.6.2 Credit Card Vendor

9.1.1 Java Enterprise Edition

9.1.3 PHP Hypertext Pre-processor

9.1.4 Cascading Style Sheets