Diss

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
Mark Bradley (mdb2)
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:
Mark Bradley (mdb2)
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.
Mark Bradley (mdb2)
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.
Mark Bradley (mdb2)
4 Contents
1 2 3 4 5 6 7 8 Declaration of Originality................................................................................................. 3 Acknowledgements........................................................................................................... 4 Abstract............................................................................................................................. 5 Contents ............................................................................................................................ 6 Introduction....................................................................................................................... 8 Existing Systems............................................................................................................... 9 Methodologies ................................................................................................................ 11 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
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
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/
Mark Bradley (mdb2)
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.
Mark Bradley (mdb2)
Figure 2 Screen Shot of the Aloud website.
Figure 3 A screen shot of the Ticket Web website.
10
Mark Bradley (mdb2)
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 (mdb2)
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 (mdb2)
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 (mdb2)
8.2 Functional Requirements

After drawing up the Use Case Diagram the following functional requirements were decided upon. FR1 FR2 FR3 FR4 Allow all registered users to purchase tickets for concerts. Allow someone to register to become a user. The system will send out automated emails to validated users. 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 (mdb2)
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 ecommerce, 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 (mdb2)
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 (mdb2)
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
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
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 (mdb2)
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
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
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 (mdb2)
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
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
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 nondisabled 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 (mdb2)
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 (mdb2)
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
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
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 (mdb2)
Figure 9
30
Mark Bradley (mdb2)
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 (mdb2) 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
The database is checked for the email the user just entered. If the email already exists in the database the client is forwarded client-form.php The clients details are added to the client table. if the clients details are not added to the client table the user is forwarded to clientform.php If the clients details are added correctly, the card_setup() function is called, which inserts the clients credit card details into the card table. 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. 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. If the genres are not added to the genre table the user is forwarded to unsuccess.php and the database is rolled back. 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. If the email is not sent the user is forwarded to unsuccess.php and the database is rolled back. 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 (mdb2)
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
Mark Bradley (mdb2)
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 concertform.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 bandform.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 venueform.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 (mdb2)
venue-form.php
1 2, 4
Controller. php
venue
5 6
Venue.php
8
venue-list.php
Figure 14
35
Mark Bradley (mdb2)
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 (mdb2)
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 clientNum bigint 20 Surname firstName DOB addLine1 addLine2 varchar varchar Date varchar varchar 30 30 50 50 Comments Primary Key, Auto incrementing, not null The customers surname, not null The customers first name, not null The customers date of birth, not null The first line of the customers address, not null The second line of the customers
37
Mark Bradley (mdb2)
Dissertation CS39030 Online Ticket Sales System addess customers The customers town, not null The customers county, not null The customers postcode, not null The customers telephone number, not null The customers email address, not null The customers user name not null The customers password held in MD5 encryption not null Will equal true if use has validated account and false if the account has not been validated, not null
town county postcode telNo email userName password valid
varchar varchar varchar varchar varchar varchar varchar varchar
30 30 9 13 50 20 32 6
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 ConcertNum Bigint 20 Time Date venueNum bandNum Time Date bigint bigint 20 20 Comments Primary key and foreign key referencing the client table not null The time the concert will start not null The date the concert is held on. not null Foreign key referencing the venue table. not null Foreign key referencing the band
38
Mark Bradley (mdb2)
Dissertation CS39030 Online Ticket Sales System table. not null The date the concert ticket will be released on. not null The time the concert ticket will be release. not null The total number tickets for the concert. not null The number of tickets not sold for the concert. not null The price of the tickets. not null
releaseDate releaseTime TotalTickets
Date
bigint
20 20
RemainingTickets Bigint ticketPrice double
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 bandNum Bigint 20 name genre website picture alt desc Varchar Varchar varchar varchar varchar longtext 40 20 50 30 255 Comments Primary key, auto incrementing not null The name of the band, must be unique not null The genre of the band The website of the band the http:// not needed. The file name of picture The alternative text for the image. 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 venueNum Bigint 20 name Varchar 40 town Varchar 40 capacity bigint 20 Comments Primary key, auto increment The name of the venue The town in which the venue is situated 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 (mdb2)
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 staffNum Bigint 20 username Varchar 20 Password Varchar 32 adminLevel Smallint 6 Comments Primary key, auto increment. not null The staff member user name. not null The staff member password. not null The staff member admin level to determine the user level of access. not null The staff member first name. not null The staff member surname. not null
firstName surname
Varchar varchar
30 30
40
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
$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
Mark Bradley (mdb2)
$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
Mark Bradley (mdb2)
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"; $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
Mark Bradley (mdb2)
$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 = ""; //Creates a random String for($i = 0; $i < 6; $i++) { $string .= chr(rand(65,90)); } $_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
Mark Bradley (mdb2)
$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
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
#header { vertical-align: top; text-align: left; background-color: #<?php print $header_bg_colour; ?>; background-image: url(http://www.digitallyscarred.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.
Figure 32 an image showing a PNG background in Internet Explorer with sizingMethod set to scale.
Figure 33 an image showing a PNG background in Internet Explorer with sizingMethod set to 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
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
Figure 37 Screen shot showing Ethereal used to test that the web page was served in an encrypted state.
53
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
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 Number UT1 Testing 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.) Verify Account Wait for email to be received from the sign-up process and follow the link in the email and verify your account Login go to the websites homepage and attempt to login. Change Address Details locate the form and change some element of your address details. Change Credit Card Details locate the form and change some element of your credit card details. Change Password locate the form that allows you to change your password and change your password 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 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 User Comments
UT2
UT3 UT4 UT5 UT6
UT7
UT8
55
Mark Bradley (mdb2) UT9 UT10 UT11 UT12
Locate a band using Genres List Using the genre list find a bands information page. Locate a band using Bands List using the band list page find a bands information page Make a Purchase choose a concert you have found and go though the purchasing process 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: 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 services using the Internet? Test Number UT1 UT2 Testing Login 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.) Edit a band Edit some element of the bands you have just added details of Delete a band Delete two bands from the band list page. 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.) Add a venue Add two venues Edit a venue edit the details of one of the venues you added previously and confirm changes where made. Delete a venue delete one of the venues you added previously. Add a concert add three concerts of your choice. (note the tick box for adding multiple concerts.) Edit a concert edit some detail of one Delete a concert Send Genre email User Comments
UT3 UT4 UT5
UT6 UT7
UT8 UT9
UT10 UT11 UT12
56
Mark Bradley (mdb2) UT13 Send Band Email UT14 Add Staff member Any other comments:
57
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
Figure 38
Figure 39
59
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
Figure 46
Figure 47
63
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
Figure 56
Figure 57
68
Mark Bradley (mdb2)
Figure 58
Figure 59
69
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
Figure 66
Figure 67
74
Mark Bradley (mdb2)
Figure 68
Figure 69
75
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
Figure 84 Screen shot show the band information band for The White Stripes.
Figure 85 Screen Shot Sh
Figure 86
83
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
Figure 89
86
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
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
Mark Bradley (mdb2)
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/WAIWEBCONTENT/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
Mark Bradley (mdb2)
[17] Matt Zandstra, 2004, PHP 5 Objects, Patterns, and Practise, Apress, United States of America
91
Mark Bradley (mdb2)
13 Appendix A Manual Testing Test plan

Test Number 1 Functional Requirement FR5 Testing A venue can be added to the system Venue Name Art Centre Town/City Aberystwyth Capacity 2500 Only administrators and data entry staff can add venues Expected Outcome A staff user should be able to add information about a concert venue into the system. Actual Outcome Test Passed Staff users are able to add venues to the system
FR5
FR5, FR6
When a venue is added all required fields are filled in.
FR5, FR6
When a venue is added there are no other venues with the same name in the same city or town
FR6
That a venue information can be updated
FR6
Only administrators and data entry staff can edit venues
Only staff set as administrators and data entry staff should be able to gain access to add venues. If a staff user tries to add a venue and leaves a require field blank they are returned to the concert form and informed of the error. If a staff user tries to add a venue they should not be able to add a venue with the same name and town or city if they do they are returned to the concert form and informed of the error. A staff user should be able to update information about a concert venue that exists in the system. Only staff set as administrators and data entry staff should be able to gain
Test Passed only administrators and data entry staff can add venues. Tested Passed if some of the required fields are left blank the venue is not added and the staff user is informed so. Test Passed a venue with the same name and town/city as a venue in the database cannot be added.
Test Passed Venue information can be edited.
Test passed only administrators and data entry staff can edit
92
Mark Bradley (mdb2)
Dissertation CS39030 Online Ticket Sales System access to edit venues. A staff user should be able to remove a concert venue from the system. A venue should not be deleted if there is a concerts scheduled in the venues Only staff set as administrators and data entry staff should be able to gain access to delete venues. A staff/admin user should be able to add information about a band to the system. venues Test Passed Venues can be deleted.
FR6
A venue can be removed
FR6
A venue can not be removed if there is a concert scheduled there. Only administrators and data entry staff can delete venues
FR6
Test Passed A venue is not deleted if there is a concert scheduled there. Test passed Only administrators and data entry staff can delete venues Test Passed A band can be added to the database.
10
FR5
11
FR5
A band can be added. Name The Streets Genre Hip Hop Website www.thestreets.co.uk Description Picture Only administrators and data entry staff can add bands
12
FR5, FR6
All require fields must be completed for a band to be added
Only staff set as administrators and data entry staff should be able to gain access to add bands. If a staff user tries to add a band and leaves a required field blank they are returned to the concert form and informed of the error. If a staff user tries to add a band with the same name as another band they are returned to the concert form and informed of the error. A staff user
Test passed Only administrators and data entry staff can add bands Test Passed - All require fields must be completed for a band to be added if they are not the user is sent back to the form and informed of the error. Test Passed A band cannot be added if there is a band in the database with the same name.
13
FR5, FR6
A band cannot be added with the same name as another band.
14
FR6
A bands
Test Passed - A
93
Mark Bradley (mdb2)
Dissertation CS39030 Online Ticket Sales System information can be updated should be able to update a bands information that exists on the system. Only staff set as administrators and data entry staff should be able to gain access to edit bands. A staff user should be able to remove a band from the system. A band should not be deleted if the band has concerts scheduled. Only staff set as administrators and data entry staff should be able to gain access to delete bands. A staff user should be able to add information about a town or a city into the system. If a staff user tries to add a city / town and leaves a required field blank they are returned to the concert form and informed of the error. If a staff user tries to add a city with the same name as another city they are returned to the concert form and informed of the error. A staff user should be able to bands information can be updated
15
FR6
Only administrators and data entry staff can edit bands
Test Passed Only administrators and data entry staff can edit bands Test Passed a band can be deleted. Test Passed - A band will not be removed if they have a concert scheduled Test Passed Only administrators and data entry staff can delete bands Test Passed a city/town can be added.
16
FR6
A band can be removed
17
FR6
A band will not be removed if they have a concert scheduled Only administrators and data entry staff can delete bands
18
FR6
19
FR5
A city / town can be added. City/town: Bristol
20
FR5
When a city / town is added all require fields have been filled in
Test Passed all required fields must be filled in before the data is added to the database.
21
FR5
A city / town cannot be added twice
Test Passed a town or city can not be added twice.
22
FR5
A concert can be added
Test Passed A concert can be
94
Mark Bradley (mdb2)
Dissertation CS39030 Online Ticket Sales System Band: Feeder Venue: Arts Centre Aberystwyth 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 Only administrators and data entry staff can add concerts add information about a concert into the system. added.
23
FR5
24
FR5, FR6
All required fields must be completed for a concert to be added
25
FR6, FR6
A concert venue cannot have two concerts booked on the same date.
26
FR5, FR6
A band cannot have two concerts booked on the same day.
27
FR5, FR6
The concert date cannot be after the release date for the tickets
Only staff set as administrators and data entry staff should be able to gain access to add concerts. If a staff user tries to add a concert and leaves a required field blank they are returned to the concert form and informed of the error. If a staff user tries to add a concert for a venue when one is already booked for that date they are returned to the concert form and informed of the error. If a staff user tries to add a concert for a band when one is already booked for that date they are returned to the concert form and informed of the error. If a staff user tries to add a concert with the ticket release date set after the
Test Passed Only administrators and data entry staff can add concerts All require fields must be completed for a concert to be added or user will be returned to concert form and informed of the error. Test Passed A concert cannot be added if there is already a booking for that venue on that day.
Test Passed a concert can not be added if the band already have a concert on the given day.
Test Passed if the release date is after the concert date the concert will not
95
Mark Bradley (mdb2)
Dissertation CS39030 Online Ticket Sales System concert date they are returned to the concert form and informed of the error. be added and the user will returned to the concert form and informed of the error. Test Passed A concert can be updated.
28
FR6
That a concerts information can be updated
29
FR6
Only administrators and data entry staff can edit concerts
30
FR6
That a concerts information can be deleted
31
FR6
Only administrators and data entry staff can edit concerts
32
FR6
33
FR6
That if a concert has been released and it is deleted client with tickets booked are sent an email Test that when concert with bookings is deleted the bookings are deleted too.
A staff user should be able to update information about a concert that exists in the system. Only staff set as administrators and data entry staff should be able to gain access to edit concerts. A staff user should be able to delete concert that exists in the system. Only staff set as administrators and data entry staff should be able to gain access to delete concerts. When a concert is delete clients are informed of its cancellation
Test Passed Only administrators and data entry staff can edit concerts Test Passed A concert can be deleted.
Test passed if a concert is cancelled clients are email when it is deleted. Test Passed When a concert is delete any booking for that concert are also deleted.
34
Staff cannot buy tickets.
When a concert is delete any booking that were made for it should be deleted to keep referential integrity A user logged in as staff should not be able to buy tickets.
35
FR10
Database settings can be edited
An administrator should be able to
Test Passed A member of staff could not access the pages that allow clients to purchase tickets Test Passed Administrators
96
Mark Bradley (mdb2)
Dissertation CS39030 Online Ticket Sales System change database connection settings from the websites can change database settings and this can only be done by Administrators A administrator Test Passed should be able to Administrators change style can change style settings from the settings and this websites can only be done by Administrators Staff should be Test Passed able to send out Staff can send emails to fans of out emails to a particular fans of a genre. particular genre Test Passed Only fans of a Only fans of a particular genre genre receive should receive update emails for genre update that genre. emails Staff should be Test Passed able to send out Staff can send emails updating out email with people of a information bands concerts. about a bands concerts. Test Passed Client should Clients only only receive receive emails emails about about bands bands within the within the genre genres they they registered selected when an interest in. they signed up. Staff can send out Test Passed staff can send emails about a out birthday months events emails. and all clients with birthdays in that month receive the email. Only clients with Test Passed only clients with birthdays in the birthdays within selected month should receive an the selected month receive email. birthday emails. Upon completion Test passed of the client form users are able to sign up for the the user should be registered with site using the client form. the site.
36
FR10
That style settings can be changed
37
FR7
That an email can be sent out updating fans of a particular genre That genre update emails only got to fans of the selected genre. That an email can be sent out regarding a selected band.
38
FR7
39
FR7
40
FR7
41
FR7
That a client only receives an emails when they have shown an interest in the genre of which the band is in. Test that staff can send out birthday emails.
42
FR7
That only clients with birthdays in the selected month receive a birthday email. Test that it is possible for nonmembers of the site to sign up to become a member. First Name Mark
43
FR2
97
Mark Bradley (mdb2)
Dissertation CS39030 Online Ticket Sales System 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 All required fields must be filled in
44
FR2
45
FR2, FR4
Test that a client is not able to sign up with out entering the correct CAPTCHA string.
If a user leaves a required field blank they should be sent back to the client form and informed of the error. The client should not be allowed to sign up to the site without entering the correct CAPTCHA string.
Tested Passed If a user enters an incorrect CAPTCHA string they are returned to the client form and informed of the error.
46
FR2
47
FR3
Test that a client is not able to sign up without the password in the password and reenter password fields matching. Once someone has
The client should not be able to sign up in the site if the both passwords do not match. Once a client Test Passed
98
Mark Bradley (mdb2)
Dissertation CS39030 Online Ticket Sales System registers with the site a validation email should be sent to their given email address that will send them a link to validation page The link on the A customer is validation email validated upon will link to the following the link validation page to validation page. with the clients clientNum being used to uniquely identify the user. Before the user A customer is validates their unable to log in to account they their account until they have validated should not be able to log in to their account the website. Once they have registered they should be able to log in to the site. A client should That a client user be able to edit can edit their address details once their address they have signed in. details once they have logged into the website. registered to become a member they are sent a customer validation email That a client user can edit their credit card details once they have signed in. A client should be able to edit their credit card details once they have logged into the website. A client should be able to edit their password once they have logged into the website. The user should be shown all of the concerts for the band entered in the test box The user should Users receive a validation email upon completing the signing up process
48
FR3
Test Passed The email includes a link that allows the user to validate their account
49
FR3
Test Passed a user is not able to log in without their account being verified.
50
FR9
41
FR9
52
FR9
That a client user can change their password once they have signed in.
53
FR8
Test that the basic search works when searching for an artist returns correct results. Test that the basic
54
FR8
Test passed Users are able to change their address details once they have logged into the site. Test Passed Users are able to change their credit card details once they have logged into the site. Test Passed Users are able to change their password once they have logged into the site. Test Passed The user was shown a list of all concerts for the band entered in the text box. Test Passed the
99
Mark Bradley (mdb2)
Dissertation CS39030 Online Ticket Sales System Search for a city returns correct results. be shown all of the concerts in the town selected in the drop down menu. The user should be shown all of the concerts in the town selected in the drop down menu where the band playing is that in the text box. To stop conflicting search parameters a search can only be done on ether the artist or the genre so if the artist is set that will override the genre selection. To stop conflicting search parameters a search can only be done on ether the artist or the city/town or venue if the venue it will always override the city/town selection The date search allows to search for concerts on a given date or for concert inbetween a set of dates. If a search returns not results rather than leaving the page blank the search should be informed that their search found no concerts When tickets are not sold out and release clients user was shown a list of all concerts in the selected city. Test Passed The user is shown a list of the concerts in the selected city where the band playing is the one entered in the text box. Test Passed the artist and genre search works and brings back the correct results.
55
FR8
Test that the basic search for an artist and a city returns the correct results.
56
FR8
Test that the advanced search returns the correct results when searching by artist or genre
57
FR8
Test that the advanced search returns the correct results when searching by city/town or venue
Test Passed The city/town and venues search works and brings back the correct results
58
FR8
Test that the advanced search returns the correct results when searching by a date or set of dates. Test that if a search yields no results the user is informed so and not just shown a blank page.
Test Passed The date search works correctly and bring back the correct results. Test Passed if a search finds no results the user is informed so.
59
FR8
60
FR1
Test that a buy tickets link will only appear if
Test Passed if there are tickets available clients
100
Mark Bradley (mdb2)
Dissertation CS39030 Online Ticket Sales System tickets are available should be able to follow a link to tickets.php to start the purchasing process. If tickets are sold out client should not be able to purchase tickets are able to purchase them.
61
FR1
Test that if tickets are sold out the client is informed so.
62
FR1
Test that if tickets have not been released yet the client is informed so Test that the program totals up the price and informs the client of the total and the account the money will be taken from WAI Level A compliance
Client should not be able to buy ticket that have not yet been released On purchase.php the client should be told the total price of there purchase
93
FR1
Test Passed - If tickets are sold out the link to tickets.php is read with plain text saying sold out. Test Passed there is no link for concert tickets until the tickets are released. Test Passed The program works out the correct total for the purchase
64
FR12
65
FR12
WAI Level AA Compliance
Web pages should pass the WAI level A checklist requirements, Web pages should pass the WAI level AA checklist requirements
Test Passed See appendix # for completed checklist Test Passed See appendix # for completed checklist
101
Mark Bradley (mdb2)
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 Level of computer competence between 1 10 (1 being complete novice and 10 being 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! Test Number UT1 Testing 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.) Verify Account Wait for email to be received from the sign-up process and follow the link in the email and verify your account Login go to the websites homepage and attempt to login. Change Address Details locate the form and change some element of your address details. Change Credit Card Details locate the form and change some element of your credit card details. Change Password locate the form that allows you to change your password and change your password 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 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: User Comments Took about 2 mins to sign up.
UT2
email did not arrive!
UT3 UT4
Done Done, but no confirmation that the change has been accepted Done, but no confirmation that the change has been accepted Done, but no confirmation that the change has been accepted 2006/-7/11 No option to change the date format? Most brits use 11/7/2006
UT5
UT6
UT7
UT8
Mitchell Brothers The Streets
102
Mark Bradley (mdb2)
Artist - Steps Venue The Playhouse - Erith UT9 UT10 UT11 Locate a band using Genres List Using the genre list find a bands information page. Locate a band using Bands List using the band list page find a bands information page Make a Purchase choose a concert you have found and go though the purchasing process Log out finally log out the system OK worked (Artic Monkeys) OK worked (Artic Monkeys) Tried to buy tickets for the killers, dumped back to main screen
UT12
Any other comments on the site?
103
Mark Bradley (mdb2)
Web Browser (include any access technology used, i.e. Screen Readers): Internet Explorer 6 Age: 51 Level of computer competence between 1 10 (1 being complete novice and 10 being 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 Test Number UT1 Testing 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.) Verify Account Wait for email to be received from the sign-up process and follow the link in the email and verify your account Login go to the websites homepage and attempt to login. Change Address Details locate the form and change some element of your address details. Change Credit Card Details locate the form and change some element of your credit card details. Change Password locate the form that allows you to change your password and change your password 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 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 UT9 Locate a band using Genres List Using the genre list find a bands information page. Used this to locate Ska, Madness got details of band User Comments Ok Easy to follow instructions
UT2
UT3 UT4 UT5 UT6
OK e-mail sent back almost immediately OK entered site immediately Changed telephone number details, easy to do Changed type of card, easy to do Changed password. Eay to follow instructions OK, easy to follow instructions
UT7
UT8
Easy to follow instructions Results were Street or Mitchell Bros. The 2nd search produced no results, assume this was correct. The 3rd search also produced no results, I wonder why?
104
Mark Bradley (mdb2)
Dissertation CS39030 Online Ticket Sales System on screen
UT10 UT11 UT12
Locate a band using Bands List using the band list page find a bands information page Make a Purchase choose a concert you have found and go though the purchasing process Log out finally log out the system
Used list, to locate Red Hot Chilly Peppers Made a purchase for Madness tickets. Logged Out
Any other comments on the site? 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
Mark Bradley (mdb2)
Web Browser (include any access technology used, i.e. Screen Readers): Internet Explore 6 Age: 23 Level of computer competence between 1 10 (1 being complete novice and 10 being 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. Test Number UT1 Testing 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.) Verify Account Wait for email to be received from the sign-up process and follow the link in the email and verify your account Login go to the websites homepage and attempt to login. Change Address Details locate the form and change some element of your address details. User Comments ok
UT2
UT3 UT4
The link that you get sent inst one you can click on you have to cut and paste it ok Changed, but wouldnt it be good if once you clicked on change it said changes have been successful? Same as above, casue you dont know if its changed it
UT5 UT6
UT7
UT8
Change Credit Card Details locate the form and change some element of your credit card details. Change Password locate the form that allows you to change your password and change your password 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 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
Dont like the date format
Fine
Wouldnt the venues be better in alphabetical order?
106
Mark Bradley (mdb2) UT9 UT10 UT11 UT12
Dissertation CS39030 Online Ticket Sales System ok ok ok ok
Locate a band using Genres List Using the genre list find a bands information page. Locate a band using Bands List using the band list page find a bands information page Make a Purchase choose a concert you have found and go though the purchasing process Log out finally log out the system
Any other comments on the site?
107
Mark Bradley (mdb2)
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, 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 color, for example from context or markup. 4.1 Clearly identify changes in the natural language of a document's text and 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 still be possible to read the document. 6.2 Ensure that equivalents for dynamic content are updated when the dynamic content changes. 7.1 Until user agents allow users to control flickering, avoid causing the screen to flicker. 14.1 Use the clearest and simplest language appropriate for a site's content. And if you use images and image maps (Priority 1) 1.2 Provide redundant text links for each active region of a server-side image map. 9.1 Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape. And if you use tables (Priority 1) 5.1 For data tables, identify row and column headers. 5.2 For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells. And if you use frames (Priority 1) 12.1 Title each frame to facilitate frame identification and navigation. And if you use applets and scripts (Priority 1) 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 equivalent information on an alternative accessible page. And if you use multimedia (Priority 1) 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 visual track of a multimedia presentation. 1.4 For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of Yes No N/A Yes No N/A Yes No N/A Yes No N/A Yes No N/A
108
Mark Bradley (mdb2)
the visual track) with the presentation. And if all else fails (Priority 1) 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 information (or functionality), and is updated as often as the inaccessible (original) page. Yes No N/A
15.1.1.1.2
2.2 Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when 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. 3.3 Use style sheets to control layout and presentation. 3.4 Use relative rather than absolute units in markup language attribute values 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. 3.7 Mark up quotations. Do not use quotation markup for formatting effects such as indentation. 6.5 Ensure that dynamic content is accessible or provide an alternative presentation or page. 7.2 Until user agents allow users to control blinking, avoid causing content to 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 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 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 without informing the user. 11.1 Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported. 11.2 Avoid deprecated features of W3C technologies. 12.3 Divide large blocks of information into more manageable groups where natural and appropriate. 13.1 Clearly identify the target of each link. 13.2 Provide metadata to add semantic information to pages and sites. 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.
109
Mark Bradley (mdb2)
Dissertation CS39030 Online Ticket Sales System And if you use tables (Priority 2) Yes No N/A
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 (which may be a linearized version). 5.4 If a table is used for layout, do not use any structural markup for the purpose of visual formatting. And if you use frames (Priority 2) 12.2 Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone. And if you use forms (Priority 2) 10.2 Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned. 12.4 Associate labels explicitly with their controls. And if you use applets and scripts (Priority 2) 6.4 For scripts and applets, ensure that event handlers are input deviceindependent. 7.3 Until user agents allow users to freeze moving content, avoid movement in pages. 8.1 Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies [Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2.] 9.2 Ensure that any element that has its own interface can be operated in a device-independent manner. 9.3 For scripts, specify logical event handlers rather than device-dependent event handlers. Yes No N/A Yes No N/A Yes No N/A
15.1.1.1.3
4.2 Specify the expansion of each abbreviation or acronym in a document where it first occurs. 4.3 Identify the primary natural language of a document. 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 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) 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 mechanism. 13.6 Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group. 13.7 If search functions are provided, enable different types of searches for
110
Mark Bradley (mdb2)
different skill levels and preferences. 13.8 Place distinguishing information at the beginning of headings, paragraphs, lists, etc. 13.9 Provide information about document collections (i.e., documents comprising multiple pages.). 13.10 Provide a means to skip over multi-line ASCII art. 14.2 Supplement text with graphic or auditory presentations where they will facilitate comprehension of the page. 14.3 Create a style of presentation that is consistent across pages. And if you use images and image maps (Priority 3) 1.5 Until user agents render text equivalents for client-side image map links, provide redundant text links for each active region of a client-side image map. And if you use tables (Priority 3) 5.5 Provide summaries for tables. 5.6 Provide abbreviations for header labels. 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 other) for all tables that lay out text in parallel, word-wrapped columns. And if you use forms (Priority 3) 10.4 Until user agents handle empty controls correctly, include default, placeholding characters in edit boxes and text areas. Yes No N/A Yes No N/A Yes No N/A
111

Diss

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Diss

Enviado por

Direitos autorais:

Formatos disponíveis

Mark Bradley (mdb2)

Dissertation CS39030 Online Ticket Sales System

Online Ticket Booking System

Mark Bradley (mdb2)

Dissertation CS39030 Online Ticket Sales System

Mark Bradley (mdb2)

Dissertation CS39030 Online Ticket Sales System

Mark Bradley (mdb2)

Dissertation CS39030 Online Ticket Sales System

Mark Bradley (mdb2)

Dissertation CS39030 Online Ticket Sales System

Mark Bradley (mdb2)

Dissertation CS39030 Online Ticket Sales System

Mark Bradley (mdb2)

Dissertation CS39030 Online Ticket Sales System

Mark Bradley (mdb2)

Dissertation CS39030 Online Ticket Sales System

Figure 1 Screen shot of the Ticket Master website.

Mark Bradley (mdb2)

Dissertation CS39030 Online Ticket Sales System

Figure 2 Screen Shot of the Aloud website.

Figure 3 A screen shot of the Ticket Web website.

Mark Bradley (mdb2)

Dissertation CS39030 Online Ticket Sales System

Mark Bradley (mdb2)

Dissertation CS39030 Online Ticket Sales System

Mark Bradley (mdb2)

Dissertation CS39030 Online Ticket Sales System

8.1 Use Case Diagrams

Figure 4 The User Case Diagram

Mark Bradley (mdb2)

Dissertation CS39030 Online Ticket Sales System

8.2 Functional Requirements

Mark Bradley (mdb2)

Dissertation CS39030 Online Ticket Sales System

8.3 Extra Functionality 8.4 Security

8.4.1 Structured Query Language (SQL) Injection

8.4.1.1 Preventing SQL Injection

Mark Bradley (mdb2)

Dissertation CS39030 Online Ticket Sales System

8.4.2 Cross Site Scripting (XSS)

8.4.2.1 Preventing XSS

8.4.3 Session Hijacking

Mark Bradley (mdb2)

Dissertation CS39030 Online Ticket Sales System

8.4.3.1 Listening to network traffic

8.4.3.2 Phishing, forwarding and proxies

8.4.3.3 Session Fixation

Mark Bradley (mdb2)

Dissertation CS39030 Online Ticket Sales System

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)

Mark Bradley (mdb2)

Dissertation CS39030 Online Ticket Sales System

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.