Online Ticket Booking System

slicedmitesSecurity

Feb 16, 2014 (3 years and 6 months ago)

104 views

Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
Online Ticket Booking System
CS39010 Dissertation


Author: Mark Bradley
Supervisor: Chris Loftus
Year of Submission: 2006
2
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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 University’s regulations governing these issues.

Signature:

Name: Mark Bradley

Date:
3
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem


Figure 2 – Screen Shot of the Aloud website.


Figure 3 – A screen shot of the Ticket Web website.
10
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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 don’t 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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem

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 user’s 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 hacker’s server which then forwards the user on to the
site they thought they were going to. Now the hacker’s server is setup as a proxy in-between
the client browser and real website’s 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.


Figure 5 – an example Phishing URL.
http://www.barclays.co.uk.customercare.goto.manicte.com/r1/b/


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.


Figure 6 – An example URL used for session fixation.
www.example-site.com?SESSID=1234

17
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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 user’s
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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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 clown’s
trousers? Or what colour is the clown’s 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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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 user’s 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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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 can’t 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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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 8
th
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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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 Java’s 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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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
browser’s 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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem

Figure 9

30
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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 client’s details are added to the client table.
9. if the client’s details are not added to the client table the user is forwarded to client-
form.php
10. If the client’s details are added correctly, the card_setup() function is called, which
inserts the client’s 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 client’s 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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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 client’s 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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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 band’s 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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
venue-form.php
Controller.
php
venue
Venue.php
venue-list.php
1
2, 4
3
5
6
8
7

Figure 14

35
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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 client’s 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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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
Field Name
Field Type
Field Length
Comments
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.
Field Name
Field Type
Field Length
Comments
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.
Field Name
Field Type
Field Length
Comments
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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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.
Field Name
Field Type
Field Length
Comments
gnere
varchar
30
Primary key not null

9.6.6 Band
The band table is used to store the bands details
Field Name
Field Type
Field Length
Comments
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.
Field Name
Field Type
Field Length
Comments
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.
Field Name
Field Type
Field Length
Comments
town
varchar
40
Primary key

39
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
9.6.9 Booking
The booking table hold the details of all the bookings made.
Field Name
Field Type
Field Length
Comments
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.
Field Name
Field Type
Field Length
Comments
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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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.


Figure 16 – The code used to ensure that forms have not been sent from another website.
$ref = preg_match("/www.digitally-scarred.co.uk/", $_SERVER['HTTP_REFERER']);
if($ref == 0)
{
header("location: unsuccess.php");
}
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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem

Figure 17 – The code used to test input from forms for null values and unwanted characters.
$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");
}

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
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem

Figure 18
$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 19
if($form_id == "logout")
{
unset($_SESSION['logged_in']);
unset($_SESSION['user']);
session_regenerate_id();
header("location: index.php");


}

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


Figure 20 – the code for version 1 of the CAPTCHA image.
<?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");

43
Mark Bradley (m
db2)

Dissert
a
tion CS39030

Online Ticket Sales Sy
stem
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 = "";

//Creates a random String
for($i = 0; $i < 6; $i++)
{
$string .= chr(rand(65,90));
}
$_SESSION['string'] = $string;

$font_size = 14;
$font = "arial.ttf";