Online Ticket Booking System - · PDF fileOnline Ticket Sales System ... The project was to...

Mark Bradley (mdb2) Dissertation CS39030 Online Ticket Sales System

Online Ticket Booking System CS39010 Dissertation Author: Mark Bradley Supervisor: Chris Loftus Year of Submission: 2006

2


1 Declaration of Originality This submission is my own work, except where clearly indicated. I understand that there are severe penalties for plagiarism and other unfair practice, which can lead to loss of marks or even the withholding of a degree. I have read the sections on unfair practice in the Students’ Examinations Handbook and the relevant sections of the current Student Handbook of the Department of Computer Science. I understand and agree to abide by the University’s regulations governing these issues. Signature: Name: Mark Bradley Date:

3


2 Acknowledgements I would like to thank firstly Chris Loftus my dissertation Supervisor for his continued support throughout the project. My family for the emotional and financial support throughout my time at university, especially my parents who always believed in me and not complaining too much about the about the 5 hour drive from London! My long suffering Girlfriend Miranda Williams for her support and late night phone calls when everything was going wrong and I could not see a solution to a particular problem. My housemates Claire Procop, Joseph Wardell, Andrew Murray, Julian Chile and Timothy Knowles who provided relief from work on late nights with social tea breaks and making me food every once in a while. I would like to thank Simon Marshall and Gillian Price who have given advice on web accessibility and allowed me the use of software for accessibility testing and for the loan of documents regarding accessibility. Finally a big thanks Janet Roland from the Learning Languages Centre who have read over this documents too many times to mention.

4


3 Abstract This document is a report on the progression and problems that occurred throughout the project and finishes with a conclusion on the outcome of the project. The project was to create an online ticket booking system, which took into consideration the many security issues involved with programming for the Internet, securing from the varying type of attack that hackers can use, including:

• SQL injection • Cross Site Scripting • Session Hijacking

The website also the into account accessibility of the website when the layout and structure of the site was being designed. The research will include payment solutions available for such a system could use to accept customer payments. The project will take the best feature of existing ticket sales website and improve them and will implement new feature that it is felt will improve customers experience with the site. This document is accompanied by a CD, containing all the PHP, CSS and include files.

5


4 Contents 1 Declaration of Originality................................................................................................. 3 2 Acknowledgements........................................................................................................... 4 3 Abstract............................................................................................................................. 5 4 Contents ............................................................................................................................ 6 5 Introduction....................................................................................................................... 8 6 Existing Systems............................................................................................................... 9 7 Methodologies ................................................................................................................ 11 8 Project requirements ....................................................................................................... 12

8.1 Use Case Diagrams ................................................................................................ 13 8.2 Functional Requirements ....................................................................................... 14 8.3 Extra Functionality................................................................................................. 15 8.4 Security .................................................................................................................. 15

8.4.1 Structured Query Language (SQL) Injection..................................................... 15 8.4.2 Cross Site Scripting (XSS) ................................................................................ 16 8.4.3 Session Hijacking .............................................................................................. 16 8.4.4 Password Encryption ......................................................................................... 18 8.4.5 Secure Socket Layer (SSL)................................................................................ 18 8.4.6 Allowing only human users ............................................................................... 19 8.4.7 Verifying your users .......................................................................................... 21 8.4.8 Maintaining a secure environment..................................................................... 21 8.4.9 Security Functionality........................................................................................ 21

8.5 Web Accessibility and Usability............................................................................ 23 8.5.1 Web Usability .................................................................................................... 23 8.5.2 Accessibility Law .............................................................................................. 23 8.5.3 Online Testing ................................................................................................... 23 8.5.4 Web Content Accessibility Guidelines 1.0 (WCAG 1.0) .................................. 24 8.5.5 Publicly Available Specification – 78: Guide to good Practise in Commissioning Accessible Websites (PAS 78) ....................................................................................... 24 8.5.6 Conclusion ......................................................................................................... 25

8.6 Online Finance Systems......................................................................................... 26 8.6.1 PayPal and WorldPay ........................................................................................ 26 8.6.2 Credit Card Vendor............................................................................................ 26 8.6.3 Conclusion ......................................................................................................... 26

9 Implementation ............................................................................................................... 27 9.1 Technology ............................................................................................................ 27

9.1.1 Java Enterprise Edition ...................................................................................... 27 9.1.2 ASP.................................................................................................................... 27 9.1.3 PHP Hypertext Pre-processor ............................................................................ 27 9.1.4 Cascading Style Sheets ...................................................................................... 27

9.2 Website Design and layout .................................................................................... 29 9.3 Human Computer Interaction................................................................................. 29 9.4 Site Layout ............................................................................................................. 31

9.4.1 Client Side ......................................................................................................... 31 9.4.2 Administrator Side............................................................................................. 34

9.5 Site Design (Page Layout) ..................................................................................... 36 9.6 Database Design..................................................................................................... 37

9.6.1 Client ................................................................................................................. 37 9.6.2 Card ................................................................................................................... 38 9.6.3 Genre ................................................................................................................. 38 9.6.4 Concert............................................................................................................... 38 9.6.5 Genres................................................................................................................ 39 9.6.6 Band................................................................................................................... 39

6


9.6.7 Venue................................................................................................................. 39 9.6.8 Town.................................................................................................................. 39 9.6.9 Booking ............................................................................................................. 40 9.6.10 Staff ............................................................................................................... 40

9.7 Implementation Process ......................................................................................... 41 9.7.1 Featured Code.................................................................................................... 41

9.8 Problems during Implementation........................................................................... 48 9.8.1 PHP.................................................................................................................... 48 9.8.2 Accessing Objects held as a session variable .................................................... 48 9.8.3 Database............................................................................................................. 48 9.8.4 General............................................................................................................... 49

10 Testing ............................................................................................................................ 54 10.1 Testing PHP applications ....................................................................................... 54 10.2 Test Plan................................................................................................................. 54 10.3 Accessibility Testing.............................................................................................. 54 10.4 User Testing ........................................................................................................... 54

10.4.1 Client Side User Testing................................................................................ 55 10.4.2 Administration Side User Testing ................................................................. 56

10.5 Cross-Browser Compatibility Testing.................................................................... 58 10.6 Testing Outcomes .................................................................................................. 58

11 Critical Review ............................................................................................................... 87 11.1 Methodology .......................................................................................................... 87 11.2 PHP ........................................................................................................................ 87 11.3 CSS ........................................................................................................................ 87 11.4 Security .................................................................................................................. 87 11.5 Accessibility........................................................................................................... 88 11.6 Testing.................................................................................................................... 88 11.7 Improvements ........................................................................................................ 88 11.8 Overall.................................................................................................................... 89

12 Bibliography ................................................................................................................... 90 13 Appendix A Manual Testing – Test plan........................................................................ 92 14 Appendix B - results of user testing.............................................................................. 102 15 Appendix C - WAI........................................................................................................ 108

7


5 Introduction This purpose of the CS39030 (dissertation) project is to produce an online ticket ordering system. This document reports the design, implementation and testing of the system. The project will concentrate on ensuring the web site is secure from the varying type of attack that hackers can use, including:

• SQL injection • Cross Site Scripting • Session Hijacking

The website will allows be design with accessibility in mind. Existing ticket sales websites will researched to ensure that the site has a fighting chance of competition with them. The report will look at the look at important parts of code and problems during the project and how those problems were over come. The documentation will cover the testing of the project once the implementation stage of the project is over. The website produced by this project can be found at: http://www.digitally-scarred.co.uk/dis/

8

http://www.digitally-scarred.co.uk/dis/


6 Existing Systems There are currently a number of different websites offering online tickets sales. Some of the most well known are:

• Ticket Master (www.ticketmaster.co.uk), Figure 1. • Aloud (www.aloud.com), Figure 2. • Ticket Web (www.ticketweb.co.uk), Figure 3.

Each site of the site offers a very similar service to their customers. The sites each have a different way of navigating and searching the site. Ticket master and aloud include links on their home page to what they describe as ‘hot tickets’ linking to pages selling latest tickets. The Ticket Web site home page requires the user to select an area of the county or they must search for an artist or event there is no mention what tickets they have available. The search facilities available on each of the sites are similar. The search on Ticket Master allows users to search by artist, team or venue in a chosen location. The Aloud website has a basic search comprising of artist/band or town. The advanced search allows users to search by artist or event, a set of dates, a venue name and a town. The ticket web search basic search allows users to search for artists or events. Or browse events is a select region. The Advanced search allows user to search by region a date and by key words. The ticket master website offers accounts to customers so that their details are stored so that process of purchasing tickets is quicker and customers do not have to fill in forms. Customers who have accounts receive emails periodically from the site promoting up coming events. The aloud website offers customers an email list facility where users can enter their email address to be kept up to date with up coming events.

Figure 1 – Screen shot of the Ticket Master website.

9

http://www.ticketmaster.co.uk/

http://www.aloud.com/

http://www.ticketweb.co.uk/


Figure 2 – Screen Shot of the Aloud website.

Figure 3 – A screen shot of the Ticket Web website.

10


7 Methodologies The methodology that will be used through out the development process will be a variation on the waterfall life cycle. As the requirements for the project are unlikely to change dramatically this methodology will fit the project. If the project looked like the requirements would be changing often a more agile methodology would have been chosen. The waterfall lifecycle works by following a strict path through the development process not moving on to the next stage until the previous stage has been completed. The stages for this project will be: The first stage of the project will involve researching into existing systems, user expectation and then drawing up the requirements of the project. Once we have the functional requirements have been decided upon the second stage will involve research into the non-functional requirements of the project for instance security and accessibility. Once the functional and non-functional requirements have been decided upon and the technologies to be used has been decided the system will be design. Once the design process has been completed the implementation stage can begin, although there will be no formal test driven development for this project when new features are added or code is edited the system will be tested to ensure that no bugs have been introduced into the program. Once the implementation has been completed the entire system will be thoroughly tested.

11


8 Project requirements After analysing existing system to see which of there feature were useful and how they could be improved, there was also a small amount of research done into finding out what user of the existing systems felt would improve the service offered to them. From this research the requirement for this project where drawn up. It was decided when the website was produced for this project will allow client to sign up to the site enabling them to purchase tickets quicker by limiting the amount of forms they have to fill in when purchasing the tickets as most details could be held in the database. Neither of the two website offering email updates attempt to personalise emails to the users tastes in music. This project will attempt to make the emails to client a little more personal by sending them emails inform them on events for genres they have shown an interest and the system will also send out birthday emails informing clients events happening close to their birthdays. Hopefully the personal touch of the website will keep the site ahead of competing websites. To improve on the search facilities offered by the existing systems. This project will over a basic search to allow users to make a quick search of the concerts and an advanced search on a separate page. so that users can restrict the search further. The search parameter will be made up of the most useful search parameters from existing systems.

12


8.1 Use Case Diagrams Use Case Diagrams were drawn up to aid in the gathering of functional requirements. Figure 4 shows the Use Case Diagram.

Figure 4 – The User Case Diagram

13


8.2 Functional Requirements After drawing up the Use Case Diagram the following functional requirements were decided upon. FR1 Allow all registered users to purchase tickets for concerts. FR2 Allow someone to register to become a user. FR3 The system will send out automated emails to validated users. FR4 The user signup form should test that the form is filled in by a human and not a

computer program. FR5 Allow admin/staff users to add:

• Venues • Bands • Concerts • Cities/Towns • Genres

FR6 Allow admin/staff users to edit and delete: • Venues • Bands • Concerts

FR6 The System will allow for semi automated emails, including: • Genre update emails • Birthday emails • Band Update emails

FR7 The system will allow clients to search for concerts by: • Date • A set of dates • Genre • Band • Venue • City/Town

FR8 A client user should be able to edit some of their information • Contact Details

o Address o Telephone Number o Email address

• Credit Card Details • Password

FR9 The system will allow admin/staff users to make changes to certain settings including:

• Database o Username o Password o Database Name

• Style and Formatting, without having to edit any PHP or CSS code. FR10 The website should be simple to use for both client and staff so that a manual is not

required for either user, although some tool tips may be required on the administration side of the site.

FR11 The system will adhere to World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI) level AA web accessibility guidelines.

14


8.3 Extra Functionality

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

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

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

15


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

8.4.2.1 Preventing XSS The use of POST requests make a site more secure from XSS attack than using GET requests. So web site developers should use POST requests as much as possible to strengthen their websites again XSS attacks. Another method of protecting against XSS attacks is to not allow any HTML markup to be entered into forms on a website unless it is absolutely necessary. Any HTML markup can simply be removed by the program processing the incoming data. If HTML input is required then rather than allowing all tags to be used filter, input and remove certain tags, for instance:

• <applet> • <embed> • <script> • <object>

Scripts should also remove attributes from the tags as these can contain Java Script. Programs should allow filter and URLs that are inputted. Normal procedure for many web applications is to remove any GET variables from the end of the URL.

8.4.3 Session Hijacking Session hijacking is when a malicious user of a site sets up valid sessions on that site to gain access to the site without having to give a username or password to login. The idea of a session was devised to allow for variables to be held in between communications with the servers and clients. Before sessions HTTP was a completely stateless protocol, meaning there was no way for the server to remember what clients it has been communicating with and what it has sent to the server and the client has no memory of which server it has been communicating with and what it has sent. Sessions were introduced to allow information to be remembered between communications. The session data is held on the server and given a unique session ID which is sent to the client, then the client references this session ID when it communicates with the servers. Anything saved as a session variable is stored in a temporary file on the server named with the session ID.

16


The session ID can be stored by the client in two ways. The first is to store it in a cookie if they are enabled. If cookies are disabled then the session ID can be appended onto the end of the URL as a $_GET variable. There are a number of different ways for hackers to intercept the session ID. They are:

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

8.4.3.2 Phishing, forwarding and proxies These forms of session hijacking convince the user’s browsers it is connecting to one server when it is actually connecting to another. Hackers using these methods can often get users to click on a seemingly innocent link for the website they wish to hijack sessions on, but the link does not go to the site it link claim to instead it forwards the user onto the hacker’s server which then forwards the user on to the site they thought they were going to. Now the hacker’s server is setup as a proxy in-between the client browser and real website’s server and is able to collect all session ID and any other information sent between the client and the server including user names, password or credit card details. Internet users can spot a link that does this by its long URL, figure 5 shows an example of a Phishing URL. To the less experienced Internet user the domain looks like it is barcalys.co.uk when actually it is manicte.com.

Figure 5 – an example Phishing URL.

http://www.barclays.co.uk.customercare.goto.manicte.com/r1/b/

However many users of the Internet are now wary of the long URLs that are used by hacker for such methods. Hackers are also making use of the ever-increasing number of available Wi-Fi connections in public places such as pubs, station, cafes and airports. There are two methods hackers use to intercept session ID and user information on such networks. The first is to set the network up so that all Internet connection goes via a proxy server on the network that collects all the data being transmitted over the network. The second method is a little more complicated to set up and involves the network vender configuring the networks Domain Name Server (DNS) by hand so that when a user enters a URL in their web browser, they believe they are being sent to the real website when actually they are not and again a proxy is being set up and the data being recorded at the proxy.

8.4.3.3 Session Fixation A hacker can make use of the facility for allowing session ID to be passed as $_GET variable and create a link with a falsified session ID in the URL. An example of this type of URL can be seen in figure 6. When a user of the site uses the link to get to the website and logs in the session ID that the hacker made up will know be a valid session ID that the hacker can use.

Figure 6 – An example URL used for session fixation.

www.example-site.com?SESSID=1234

17

http://www.example-site.com/?SESSID=1234

http://www.barclays.co.uk.customercare.goto.manicte.com/r1/b/


8.4.3.4 Preventing Session Hijacking There are number of different ways to prevent session hijacking and abuse, including the following;

8.4.3.4.1 Secure Socket Layer (SSL) The use of SSL is the most highly recommended method for preventing session hijacking. This is because any data being sent between the client and the server and visa versa is encrypted so users are protected against hackers that are listening in on the network traffic.

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

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

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

8.4.4 Password Encryption All of the passwords for both staff and client sides of the site will be stored in the database. In case a hacker manages to gain access to the database or a malicious employee gains access to the database, all the passwords need to be encrypted so that they can not be read or used. This is particularly important as many people that use the Internet only use one or two different passwords enabling any hacker to make use of this information to gain access to a user’s email account or another Internet service. There are a number of different types of encryption available with PHP including:

• MD5 • Sha1 • CRC32 • Blowfish

Passwords should never be encrypted with a reversible encryption and you should only use known encryption like the method listed previously rather than making up your own encryption algorithm.

8.4.5 Secure Socket Layer (SSL) Normally any webpage served up by a HTTP server is not encrypted so any content can be simply read if any transmissions are intercepted. Many websites that deal with sending and

18


receiving of data including address, credit card and other personal data between clients and servers. do not want this information easily intercepted. So they want to implement some kind of security of the connection between the server and the client machine or encrypt any data being sent between them. SSL requires the web server hosting the website being set up to use SSL; it also requires a third party to sign the certificate to certify the web server is who it says it is. Finally the programmer of the website has to implement a website that sends the data via the SSL connection

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

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

8.4.6.2 Cognitive CAPTCHAs A cognitive CAPTCHA relies on the user to make a choice for a selection of possibilities. Some cognitive CAPTCHA present the user with a selection of images and ask the user to select which image does not fit in with the others. An example of this type of cognitive CAPTCHA can be seen in figure 7; the odd image out in this group would be the image of the tent as all the other images are of computers.

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

19


Another type of cognitive CAPTCHA shows the user an image and then the user is asked a simple question about the given picture. An example of this type of cognitive CAPTCHA can be seen in figure 8, A question about this image could be what colour are the clown’s trousers? Or what colour is the clown’s hat?.

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

The use of images in cognitive CAPTCHA is limited as the time it takes to collect the images and write the program to test users’ responses is too long… So, another form of cognitive CAPTCHA has been developed that uses plain text. This enables it to be read by a screen reader therefore making the CAPTCHA more accessible. There are a number of ways that this type of plain text cognitive CATPCHA can be implemented, the simplest form of which can be seen on the Warwick University blog site (http://blog.warwick.ac.uk). The user is asked to answer a simple question, for instance; what colour is an apple? Or, how many wheels does a bicycle have? The second variation of the plain text CAPTCHA is to misspell a word having white space between each letter to ensure a screen reader will read each letter separately. Then the user is asked to enter the correct spelling of the word. The final method make use of a language that has developed from chat room known as L33T SP34k (elite speak), or a language originating from short message service (SMS message or text message) messaging and chat rooms, that is know as text speech. The user is shown a word or sentence written in this language and asked to translate it into English.

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

20

http://blog.warwick.ac.uk/

http://www.hotmail.com/


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

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

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

8.4.9 Security Functionality The intention for this project is to attempt to make the application as secure as possible by implementing most of the methods indicated above. The application should be protected against cross site scripting, SQL injection and session hijacking attacks. As both staff and client users do not need to enter HTML tag or SQL statements, all input will be filtered to remove HTML tag and any special characters.

21


Commenting of code can be dangerous so all commenting will be kept within the server side scripting. This is done to ensure that a malicious user cannot read comments that could help them find security holes easier by just viewing the source. To protect against session hijacking all sessions will have a set lifetime so that a clients user sessions will only last for 20 minutes and staff user sessions will last for an hour allowing them to get work done. The session ID will also be changed when the user logs in and out of the website. There are security measures that are out of developers’ hands especially if they do not have large amounts of control over the web server. Things like firewalls play an important part in securing web applications as do whether they have SSL at their disposal or whether error messages from server side scripting is displayed.

22


8.5 Web Accessibility and Usability Web accessibility is not a recent idea. The WC3 WCA 1.0 specifications have been around since early 1999, but it has only recently been wide spread public knowledge. The British Standard Institute defines accessibility of websites as “Ability of people with disabilities to perceive, understand, navigate and interact with websites”[1] Jakob Nielsen has a view on web accessibility that: “In addition to regulatory compliance and common human decency, there are hard-nose business reasons to web designs accessible for users with disabilities. Often disabled users become very loyal customers once they find vendors who give them good service and accommodate their special needs.”[11]

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

8.5.2 Accessibility Law There is no law in the United Kingdom that states that websites must be accessible and as yet there have been no cases against companies with regards to the accessibility of their website, so nobody has a benchmark of how accessible a website need to be. However there are parts of the Disability Discrimination act 1995 revised in 2005 that could be used to cover websites if someone wished to bring someone to court for not making their website accessible. For instance the law states: Disability Discrimination act 1995 Part III section 19. “(1) It is unlawful for a provider of services to discriminate against a disabled person. (a) In refusing to provide or deliberately not providing, to the disabled person any service which he provides, or is prepared to provide to members of the public;”[7] This could include a large number of websites on the Internet including Sales Websites (Tesco, Play, Amazon, Ticket Master, this project) or online banking systems

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

23

http://webxact.watchfire.com/


8.5.4 Web Content Accessibility Guidelines 1.0 (WCAG 1.0) WCAG 1.0 is the World Wide Web Consortium (W3C) guidelines for producing accessible web content. The guidelines are split up into three different levels, to denote the level of accessible features implemented on the webpage. These levels are known as priority 1 – 3 or Web Accessibility Initiative (WAI) A, AA and AAA.

8.5.4.1 Priority 1 Priority 1 or WAI A guidelines are pretty simple to conform to and are generally ensuring that web site developers conform to general good practises of web site design, for instance:

• Ensure that all non-text elements on a website have a textual equivalent. • Produce web pages that are readable when style sheets are not applied. • When using data tables ensure that row and column headers are identified.

The priority 1 guidelines for web accessibility are pretty simple to meet and a reasonable requirement for this website is to meet the guidelines set out by the W3C.

8.5.4.2 Priority 2 Priority 2 or WAI AA guidelines are a little bit more difficult to comply with. Although they still cover some of the good practises that most web developers adhere to, they also include some specific to users’ needs including things like;

• Ensuring that background and foreground colour contrast enough so that they can be viewed on a black and white monitor or by a colour-blind user.

• Avoid using blinking content. •

The priority 2 guidelines require a little extra programming other than regular good practise web site design. They also require some training on the part of any people that will be entering data in to ensure the upkeep of the website. However despite these, it is best to ensure the priority 2 guidelines.

8.5.4.3 Priority 3 Priority 3 or WAI AAA can be a lot more difficult than the previous two priorities. A lot of the recommendation can not be judged by a program such as an online testing application. Examples of the recommendations are:

• Expand Acronym and abbreviation with the appropriate Tags. • Indicate the language the document is written in. • Provide Summaries for tables.

The priority 3 guidelines are a little more difficult to meet but are possible to meet with some extra programming on the site design, however, they increased workload on data entry staff. For this reason it will not be a requirement to meet priority 3 guideline for the website.

8.5.5 Publicly Available Specification – 78: Guide to good Practise in Commissioning Accessible Websites (PAS 78)

PAS 78 was released on the 8th March 2006. It was developed by the British Standards Institute (BSI), and is the BSI recommendation on how to construct and test a website for accessibility.

24


The document points out that having an accessible website does not just benefit disabled users. It also makes it easier for non-disabled people to use the website. It also points out the following the WAI guidelines can also increase your websites visibility to and rating for search engines. This document confirms my belief that automated tests can produce false positives and the user testing will find problems that automated testing will not. The document suggests that user testing and site design be done with disabled and non-disabled users to guarantee website designers are ensuring the website is usable and accessible from the beginning of development. Overall the document seems to be aimed at management or corporate level rather than web developers or web development companies. The document is aimed at what it defines as website commissioner: “Individual or organisation responsible for designing and building a website or web content.”[1] The document recommends not to use just one form of testing. It recommends using a number of different forms of testing including:

• Conformance Testing – this testing requires you to check that a website meets the guidelines of any the website claims to meet. E.g. WAI AA

• User Testing – this testing involves getting a number of target users. These users are given a selection of different tasks to perform when using the website then how the users get on with these tasks is recorded.

Along with user testing and conformance testing the document recommends expert reviews throughout development as “They are useful for identifying quality and consistency issues not typically identified during user testing. However , they do not find the same type or number of problems as user testing;” [1] A lot of the suggesting made in the document seems to be about giving individuals or organisations looking to make their website accessible things to think about while the website is being produced, from conception to the finished website.

8.5.6 Conclusion To ensure that a website is accessible the best form of testing is a combined one, making use of both the testing methods. After researching into web accessibility it was felt that extra functional requirements were needed to ensure that the site could adhere to WAI specifications. These are covered in function requirement FR11. The testing of the website will also include a number of user testing task to aid in the development of an accessible and useable website.

25


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

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

8.6.2 Credit Card Vendor All major credit card companies offer a system that allows companies to accept payments on their websites. These services are used by many major Internet companies.

8.6.3 Conclusion For this system the best type of payment system would be for the website to become a vendor for most if not all of the major credit card companies. This would allow a large majority of the UK population to purchase tickets via the My Tickets system, and many people now are very comfortable using their credit card to purchase all sort of items and services over the internet as long as they can tell that the website is secure. I felt that although online payment systems such as PayPal and WorldPay are extremely useful and have a good reputation on the internet, they are used by smaller companies. When the system is being programmed empty function will be put in place, so that it is ready for the extra programming involved with taking a payment from a customers credit card.

26

http://www.aber.ac.uk/systems/buyquota/


9 Implementation

9.1 Technology Before any programming could be done decisions needed to be made on which technologies should be used to program the project with. The following is a critical evaluation of the different programming languages that could be used to program such an online application.

9.1.1 Java Enterprise Edition Some research was done into different technologies that could be used to create the online ticket sales system. The first technology that was considered was J2EE or Java Enterprise Edition which is Java’s specification for distributed programming. This was considered because of a prior knowledge of the Java Programming language, but after some experimentation with J2EE I decided not to use this technology because of difficultly with implementation a project before. The problems occurred when trying to get the Web tier (JSPs and Servlets) to communicate with the EJB (Enterprise Java Bean) tier.

9.1.2 ASP ASP was noted as a possible language to use for server side control of the site. However due to no prior knowledge of the language it was discounted.

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

9.1.4 Cascading Style Sheets Research was done into Cascading Style Sheets (CSS) and the different ways it could be used to control both layout and style of the site. There was some experimentation with using <div> tags and CSS to controlled layout, as well as using tables to control layout with some CSS to format things like alignment and colour. Both approaches give web developers a lot of control of site layout. However pure CSS layout allows the designer to complete separate style and layout from content, whereas table based layout does not allow for complete separation of the two. This means that if a site uses pure CSS layout it could look completely different as elements of the site can be moved to any part of the page unlike tables that have a more solid construction and do not allow for this. A good example of how much control developers using pure CSS layout have is the website ‘CSS Zen Garden’, the creation of CSS expert Eric Meyers, which is not only full of

27


CSS tutorial but also uses its homepage to showcase different CSS designers, meaning the site is never the same. The use of table layout currently has one major advantage over pure CSS layout and this is the cross browser compatibility. Because of it more stable and solid structure a website that uses tables will look near enough the same as most commonly used web browsers. This is because although all current versions of web browsers support CSS layout, therefore each browser’s development team interpret the CSS standards for layout a little differently, if developers wish to use pure CSS layout they must introduce ‘hacks’ into their CSS using scripting languages such as PHP to check which browser a user is using and on that information decide which parts of the CSS to serve up. After researching into CSS, particularly its use for layout, it was decided that it would be best to use pure CSS layout to control the website as this will make expansion and updating the site easier in the long run.

28


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

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

29


Figure 9

30


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

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

Figure 10

9.4.1.1 Client Sign Up Figure 11 shows the flow of data involved in the client sign up process.

1. The clients details are sent as $_POST variables to controller.php 2. controller.php checks all the variables for null values, if there are any null values, the

CAPTCHA string do not match or the passwords do not match, the user is sent back to client-form.php.

3. If all the all the values are all ok controller.php the add_client() function is called. 4. The database is checked for any user names similar to the one the user has just chosen 5. If a user name similar the one the user has just entered already exists the user is sent

back to client-form.php

31


6. The database is checked for the email the user just entered. 7. If the email already exists in the database the client is forwarded client-form.php 8. The client’s details are added to the client table. 9. if the client’s details are not added to the client table the user is forwarded to client-

form.php 10. If the client’s details are added correctly, the card_setup() function is called, which

inserts the client’s credit card details into the card table. 11. If the credit card details are not added to the card table the user is forwarded to

unsuccess.php and the database is rolled back. 12. If the credit card details are added to the card table the genre_setup() function is

called which add the client’s choices genre to the genre table. 13. If the genres are not added to the genre table the user is forwarded to unsuccess.php

and the database is rolled back. 14. If the genres are added successfully the client_varifacation_email() function is called

which emails the client with the email they can use to verify their account. 15. If the email is not sent the user is forwarded to unsuccess.php and the database is

rolled back. 16. If the email is sent the user is forwarded to thanks.php.

Figure 11

9.4.1.2 Booking Tickets Figure 12 shows the flow of data involved in booking tickets.

1. The desired concert number passed to tickets.php as a $_GET variable 2. Number of tickets and concert number passed to purchase.php as $_POST variables 3. Number of tickets, concert number and posting address passed to controller.php as

$_POST variables. 4. Get the current number of price of tickets from the concert database and work out the

total price of the booking. 5. controller.php calls the check_availability() function in the purchase object passing

the number of tickets, concert number, client number and posting address as variables 6. Database checked for any bookings for the same concert and user as users can only

purchase one set of tickets for each concert. 7. If the user already has tickets they will be sent to unsuccess.php and the database is

rolled back 8. Information on the concert is retrieved from the concert table.

32


9. If the number of tickets remaining minus the number of ticket in the booking is greater than or equal to zero, the number of tickets remaining for that concert is edited in the concert table.

10. If the number of tickets remaining would equal less than zero the use would be forwarded to unsuccess.php and the database is rolled back

11. The user is then returned to controller.php 12. controller.php calls the make_purchase() function in the purchase object passing in

the total price of the purchases. 13. The purchase data is added to the database. 14. If the insert into the database fails the user is forwarded to unsussess.php and the

database is rolled back 15. If the data is inserted into the database successfully the function returns to

controller.php 16. controller.php calls the receive_payment() function. This function would be where

payments would be taken from their credit cards if the program was setup to take payments

17. The payment for the tickets is taken 18. If the payment is unsuccessful the user is forwarded to unsuccess.php and the

database is rolled back 19. If the payment is successful the function returns to controller.php 20. controller.php calls the confirm() function in the purchase object. 21. The information for the booking is retrieved from the booking table. 22. The client’s information is retrieved from the client table 23. The concert information is retrieved from the concert table 24. The band information is retrieved from the band table 25. An email is constructed confirming the booking and sent to the client. 26. If the email is not sent, the user is forwarded to unsuccess.php and the database is

rolled back 27. If the email is sent, the function returns to controller.php 28. The user is forwarded to thanks.php

Figure 12

33


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

9.4.2.1 Adding a Band Figure 13 shows the flow of data involved with the process of adding a band.

1. The band data is sent from the form on concert-form.php to controller.php. The data is checked for null values.

2. If there are null values or the image file is too large the user is forwarded to concert-form.php

3. controller.php checks the database for any band with names similar to the one attempting to be added.

4. If the database has any bands with a name similar to the band being added the user is forwarded to client-form.php.

5. controller.php calls the add_band() function in the band object. 6. The function attempts to upload an image to ‘images/artist/. 7. If the upload is unsuccessful the user is forwarded to band-form.php 8. If the upload is successful the band’s information is added to the database. 9. If the data is not added to the database successfully the user is forwarded to band-

form.php 10. If the band is added successfully the user is forwarded to band-list.php.

Figure 13

9.4.2.2 Editing a Venue Figure 14 shows the flow of data involved with the process of editing a venue.

1. The venue data is sent from venue-form.php to controller.php. The data is checked for null values.

2. If there are any null values the user is forwarded to venue-form.php. 3. The venue table is checked for any other venues of a similar name in the same town. 4. if there is a venue with a similar name in the same town the user is forwarded venue-

form.php. 5. The edit() function is called in the venue object. 6. The venue data is updated in the database. 7. If the update is unsuccessfully the user is forwarded to venue-form.php 8. If the update is successful the user is forwarded to venue-list.php.

34


venue-form.php Controller.php

venue

Venue.php

venue-list.php

12, 4 3

56

8

7

Figure 14

35


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

36


9.6 Database Design The database that was use for this project was MySQL. Figure 15 shows the enitity relation ship diagram for the database used by this website.

Figure 15 – A diagram showing the database design.

9.6.1 Client The client table is used to store the client’s details. Field Name Field Type Field Length Comments clientNum bigint 20 Primary Key, Auto incrementing, not

null Surname varchar 30 The customers surname, not null firstName varchar 30 The customers first name, not null DOB Date The customers date of birth, not null addLine1 varchar 50 The first line of the customers

address, not null addLine2 varchar 50 The second line of the customers

37


addess customers town varchar 30 The customers town, not null county varchar 30 The customers county, not null postcode varchar 9 The customers postcode, not null telNo varchar 13 The customers telephone number, not

null email varchar 50 The customers email address, not nulluserName varchar 20 The customers user name not null password varchar 32 The customers password held in

MD5 encryption not null valid varchar 6 Will equal true if use has validated

account and false if the account has not been validated, not null

9.6.2 Card The card table is used to store the clients credit card details Field Name Field Type Field Length Comments clientNum bigint 20 Primary Key and foreign key

referencing the client table not null type varchar 25 The type of credit card e.g. Visa or

master card not null secNum int 3 Three digit security code found on

the back of a credit card. not null cardNum varchar 20 Card number found on credit card not

null startDate varchar 7 The date the card is valid from not

null expireDate varchar 7 The date the card expires not null

9.6.3 Genre The genre table is used to store the clients chosen genres. Field Name Field Type Field Length Comments clientNum bigint 20 Primary Key and foreign key

referencing the client table. not null genre varchar 20 Primary Key and foreign key

referencing the genres table. not null

9.6.4 Concert The concert table is used to store the concerts details. Field Name Field Type Field Length Comments ConcertNum Bigint 20 Primary key and foreign key

referencing the client table not null Time Time The time the concert will start not

null Date Date The date the concert is held on. not

null venueNum bigint 20 Foreign key referencing the venue

table. not null bandNum bigint 20 Foreign key referencing the band

38


table. not null releaseDate Date The date the concert ticket will be

released on. not null releaseTime The time the concert ticket will be

release. not null TotalTickets bigint 20 The total number tickets for the

concert. not null RemainingTickets Bigint 20 The number of tickets not sold for

the concert. not null ticketPrice double The price of the tickets. not null

9.6.5 Genres The genres table is used to store all genres. Mainly used for dynamically creating menus making the site easy to keep up to date. Field Name Field Type Field Length Comments gnere varchar 30 Primary key not null

9.6.6 Band The band table is used to store the bands details Field Name Field Type Field Length Comments bandNum Bigint 20 Primary key, auto incrementing not

null name Varchar 40 The name of the band, must be

unique not null genre Varchar 20 The genre of the band website varchar 50 The website of the band the http://

not needed. picture varchar 30 The file name of picture alt varchar 255 The alternative text for the image. desc longtext The description of the band.

9.6.7 Venue The venue tables is used to store the venues details. Field Name Field Type Field Length Comments venueNum Bigint 20 Primary key, auto increment name Varchar 40 The name of the venue town Varchar 40 The town in which the venue is

situated capacity bigint 20 The capacity of the venue.

9.6.8 Town The town table is used to store all town and city. Mainly used for dynamically creating menus making the site easy to keep up to date. Field Name Field Type Field Length Comments town varchar 40 Primary key

39


9.6.9 Booking The booking table hold the details of all the bookings made. Field Name Field Type Field Length Comments bookingNum Bigint 20 Primary key, auto incrementing ,not

null clientNum Bigint 40 Foreign key referencing the client

table. not null NumTickets int 11 The number of tickets required in the

booking. not null PostingAddress varchar 255 The address for the tickets to be

posted to. Not necessarily the clients actual address. not null

concertNum bigint 20 Foreign key referencing the concert table. not null

totalPayment double The total amount the customer will have to. not null

9.6.10 Staff The staff form holds all of the staffs details. Field Name Field Type Field Length Comments staffNum Bigint 20 Primary key, auto increment. not null username Varchar 20 The staff member user name. not null Password Varchar 32 The staff member password. not null adminLevel Smallint 6 The staff member admin level to

determine the user level of access. not null

firstName Varchar 30 The staff member first name. not null surname varchar 30 The staff member surname. not null

40


9.7 Implementation Process The implementation of the system … The project makes some use of the new object orientation features available in PHP 5 a class file can be found in the ‘/classes’ directory.

9.7.1 Featured Code

9.7.1.1 Security

9.7.1.1.1 Referrers The first most basic security check is to ensure that any requests for controller.php are only coming from forms within the website and not from other websites. This check is done on both the client and administration sides of the website. The code that does this can be seen in figure 16.

Figure 16 – The code used to ensure that forms have not been sent from another website.

$ref = preg_match("/www.digitally-scarred.co.uk/", $_SERVER['HTTP_REFERER']); if($ref == 0) { header("location: unsuccess.php"); }

9.7.1.1.2 Input Validation To combat against SQL injection on the part of a malicious user or a user entering in characters that could cause problems with the program, certain character have to be removed from any inputted. The character include:

o ; o = o * o ‘ o “

There is no real need for users to enter any of these characters and some of the characters are key to making up SQL statements so they are simply removed from any input text. The code that also uses a regular expression <.*> to remove anything in-between < and >. This will protect the site from Cross Site Scripting attacks. Checking also has to be done to ensure that all required fields are not null. This is done to ensure the integrity of data in the database. The code that removes unwanted characters and checks for null field can be seen in figure 17.

41


Figure 17 – The code used to test input from forms for null values and unwanted characters.

$var_array = array("surname", "firstName", "dob_year", "dob_month", "dob_day", "addLine1", "addLine2", "town", "county", "postcode", "telNo", "email", "userName", "password", "card_type", "cardNum", "start_month", "start_year", "expire_month", "expire_year", "secNum");

$illegal_character_array = array('/\'/', '/\"/', '/;/', '/:/', '/=/'); $error_num = 0; foreach($var_array as &$var) { $$var = $_POST[$var];

$$var = preg_replace($illegal_character_array , "", $$var); if($var == "addLine2" or $var == "telNo") {

//Any variables listed above are not required and may be null.

} elseif($$var == "") { $error_num = 1; } } $dob = $dob_year."-".$dob_month."-".$dob_day; if($check == 1) {

header("location: client-form.php?surname=".$surname ."&firstName=".firstName."&addLine1=".$addLine1."&addLine2=".$addLine2."&town=".$town."&county=".$county."&postcode=".$postcode."&telNo=".$telNo."&email=".$email."&errorNum=2");

}

9.7.1.1.3 Sessions When user logs in and out of the website their session ID is change automatically. When the user logs in to the website there is a time limit set on the lifetime of the sessions. Figure 18 shows the code logging in to the site. Figure 19 shows the code for logging out.

42


Figure 18

$result = $new_client -> login($password_1, $clientNum); if($result == true) { session_regenerate_id(); ini_set("session.cookie_lifetime", 1200); $_SESSION['logged_in'] = true; $_SESSION['user'] = serialize($new_client); header("location: index.php"); exit(); }

Figure 19

if($form_id == "logout") { unset($_SESSION['logged_in']); unset($_SESSION['user']); session_regenerate_id(); header("location: index.php"); }

9.7.1.2 CAPTCHA The original CAPTCHA was quite basic. The program created a simple string 6 characters long, all in upper case using the code in figure 20

Figure 20 – the code for version 1 of the CAPTCHA image.

<?php session_start();

$image = imagecreatetruecolor(60, 30); $string = "";

//Creates a random String for($i = 0; $i < 6; $i++) {

$string .= chr(rand(65,90)); } $_SESSION['string'] = $string;

$textcolor = imagecolorallocate($image, 0, 255, 0);

imagestring($image, 4, 5, 5, $string, $textcolor);

// output the image header("Content-type: image/jpeg");

43


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


Figure 22 – the code for version 2 of the CAPTCHA image.

$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); ?>

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


Figure 24

$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 25 – an example of the CAPTCHA image created by version 3 of the CAPTCHA code.

46


Some of the code for versions 2 and 3 of the CAPTCHA has been taken from/adapted from code that can be found in Pro PHP Security by Chris Snyder and Michael Southwell pages 340 – 342 [14]

9.7.1.3 Deleting / Updating CHANGE!!! Any changes to the database that could affect other tables or tuples have to be checked with programming rather than relying on the database to do the checks itself. This must be done to maintain referential integrity throughout the database. This check can take two forms: a cascade delete in which any tuples make reference to the data being deleted, or not allowing the deletion of any data in the database if it being deleted if it is being referenced elsewhere. It was decided that the latter would be the best idea so deletion if only possible is certain parameters are met. An example of this form of check can be seen in figure 26. This is the code that deletes venues from the data, but venues can only be deleted if there are no concerts booked in them. If there are they will not be deleted.

Figure 26 – The code used for deleting a venue testing for venue use before deletion.

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); } } }

47


9.8 Problems during Implementation

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

9.8.2 Accessing Objects held as a session variable There were some difficulties accessing data objects held in session variables. This was done to cut down on accesses to the database and to speed up the processing of pages. Unfortunately accessing the individual variables stored in the session held object wasn’t 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

Figure 27 – the code used to retrieve individual variables from an object held in a session

variable.

$client = unserialize($_SESSION['user']); foreach($client as $one => $two) { $user[$one] = $two; }

9.8.3 Database During development one problem that occurred was another that was under the control of the Web Hosting Company. The problem was concerned with the type of database table that can be used to hold the information the system requires to work. There are two types of database table available for MySQL. The first is transaction-safe tables (TST) which includes InnoDB and BerkeleyDB (BDB) tables. These types of table allow the programmer to use database transaction to ensure that any data stays in a constant state. The other type of table is the not transaction-safe table (NTST), which includes MYISAM, ISAM, MERGE and HEAP. The NTST tables do not allow the programmer to use database transaction facilities. Although this makes any interaction with the data quicker, these tables do not allow transaction to be used. Unfortunately only the type of table available with the web hosting used was NTST not allowing the system to easily implement database rollback automatically. Rather, the system had to have extra programming to implement a substitute for not being able to use database transaction.

48


9.8.4 General Cross browser compatibility was a big problem during development. There were many inconsistencies between the ways that web browsers rendered a page. One of the most noticeable differences is that Internet Explorer web browsers pre version 7 do not support the transparency of Portable Network Graphics (PNG’s). 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


Figure 30 – the CSS hack use to fix the transparency problem with Internet Explorer.

#header { vertical-align: top; text-align: left; background-color: #<?php print $header_bg_colour; ?>; background-image: url(http://www.digitally-scarred.co.uk/dis/images/header/<?php print(date(n)); ?>.png); background-position: right top; background-repeat: no-repeat; position: absolute; top: 2.5%; left: 5%; right: 5%; height: 20%; width: 85%; padding-left: 5%; padding-top: 2%; padding-bottom: 0%; } * html #header { background-image: none;

filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src="http://www.digitally-scarred.co.uk/dis/images/header/<?php print(date(n)); ?>.png",

Unfortunately this hack does not allow for the positioning of the background image as it did before so with the hack applied the header now looks like it does in figure 31 if sizingMethod is set to ‘crop’. Figure 32 shows how the header is rendering if the sizingMethod is set to ‘scale’ and figure 33 show the how the header is rendered if the sizingMethod is set to ‘image’.

Figure 31 – an image showing a PNG background in Internet Explorer with sizingMethod set to

‘crop’.


‘scale’.


‘image’ However it was not noticed until user testing that these hacks have subsequent effects on other elements of the site that are on top of the image. The hack seems to turn anything placed

50


on top of the image in to part of the image, so for this site it turns the sign in form into an image making it impossible to sign in to the website. During development there was an issue with the time setting on the web server where the site was being hosted. The problem was that the web server was actually situated in Berlin, Germany so the time on the server is not GMT but GMT +1 Berlin. This could not be changed so had to be taken into account during testing. The only way to solve this problem is to switch the hosting of the site to a UK based server or get the server time set to GMT. Another problem with the web hosting was found when it came to implementing the SSL to ensure that information could not be read if intercepted. The problem was that the web hosting coming where the site was being hosted did not support SSL so this could not be used. However, as part of the Internet Services Administration (CS35910) module one of the practical’s 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 page’s contents were encrypted.

Figure 34 – Screen shot showing the first message informing the user they are about to connect to

a secure webpage and asking whether they wish to accept the certificate from an unknown authority.

51


Figure 35 – Screen shot showing the web browser Informing the user they are about to enter a secure website and asking the user if they wish to be informed when they are leaving the secure

part of the site.

Figure 36 – Screen shot showing the page that has been sent in an encrypted state. The user can

tell the site is secure by the padlock in the bottom right hand corner of the browser window.

52


Figure 37 – Screen shot showing Ethereal used to test that the web page was served in an

encrypted state.

53


10 Testing

10.1 Testing PHP applications There are a number of different ways of testing PHP application, apart from the normal manual testing. However a lot of the methods work better during development rather than final testing of the site. Some of the PHP Integrated Development Environments (IDEs) available have some form of debugging and testing tools built into them. Zend Studio (www.zend.com) is one rather expensive PHP IDE that allows for testing and debugging to be run locally without any web server software being installed. During the development of the project a trial version of the software was downloaded and used to debug some of the pages of the site. PHPUnit (www.phpunit.de) is an open source testing framework for testing PHP programs. The writers of PHPUnit have written is so that it is very similar to JUnit the testing framework for Java programs. PHPUnit requires installation on a web server. PHPUnit was design to be used for Test Driven Development. Unfortunately PHPUnit was discovered too late into the development to be used with this project. Load testing is another form of testing that would be useful for a system such as this one. Load testing involves ensuring that the servers and programming can handle the large amounts of requests a system such as an online ticket booking system can generate.

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

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

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

54

http://www.zend.com/

http://www.phpunit.de/


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

Testing User Comments

UT1 Sign-up – starting at the website homepage locate the sign-up form and fill in details, and register for site. (Please do not use real credit card detail! All other information should be true.)

UT2 Verify Account – Wait for email to be received from the sign-up process and follow the link in the email and verify your account

UT3 Login – go to the website’s homepage and attempt to login.

UT4 Change Address Details – locate the form and change some element of your address details.

UT5 Change Credit Card Details – locate the form and change some element of your credit card details.

UT6 Change Password – locate the form that allows you to change your password and change your password

UT7 Basic Search – locate the basic search form (available on every page) to do a search by band, town and band & town. Band – The Streets Town - London Band/town – Spunge/Aberystwyth

UT8 Advanced Search – Using this form complete the searching set out below. Search 1: Genre – Hip Hop City/Town: Birmingham Search 2: Venue – Alexandra Palace Date from – 11th June 2006 Date to – 21 June 2006 Search 3: Artist - Steps Venue – The Playhouse - Erith

55


UT9 Locate a band using Genres List – Using the genre list find a bands information page.

UT10 Locate a band using Bands List – using the band list page find a bands information page

UT11 Make a Purchase – choose a concert you have found and go though the purchasing process

UT12 Log out – finally log out the system Any other comments on the site? The results of the client side user testing can be seen in Appendix #.

10.4.2 Administration Side User Testing Web Browser: Age: 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 Login UT2 Add a band – Add three bands of your choice to

the database ensure you fill in all fields include uploading a photograph. (note the tick box for adding multiple bands.)

UT3 Edit a band – Edit some element of the bands you have just added details of

UT4 Delete a band – Delete two bands from the band list page.

UT5 Add a City/Town – Add two cities or towns ensuring you are not adding duplicate cities/towns. (note the tick box for adding multiple cities/towns.)

UT6 Add a venue – Add two venues UT7 Edit a venue – edit the details of one of the

venues you added previously and confirm changes where made.

UT8 Delete a venue – delete one of the venues you added previously.

UT9 Add a concert – add three concerts of your choice. (note the tick box for adding multiple concerts.)

UT10 Edit a concert – edit some detail of one UT11 Delete a concert UT12 Send Genre email -

56


UT13 Send Band Email - UT14 Add Staff member Any other comments:

57


10.5 Cross-Browser Compatibility Testing This will be done to ensure that the website works and looks similar on a variety of different browsers. The testing will be done on the most popular browsers which are:

• Mozilla Firefox • Mozilla • Microsoft internet Explorer Version 6 • Microsoft Internet Explorer Version 7 • Opera • Safari • Netscape • IBM Home Page Reader version 3.04

Testing will also be done using JAWS for Window Version 7.0. JAWS is a screen reader program produced by Freedom Scientific (www.freedomscientific.com). The software is widely used within the blind and partially sighted community to allow people to access computers using the JAWS software and a number of keyboard commands to navigate around the screen. The functioning of the website should be exactly the same as all of the programming is dealt with at the server and not by the local browser. However because of long going browser wars there can be dissimilarities between how the browsers interpret and render the HTML, and CSS sent to them can differ. The site also needs to be tested at different screen resolutions to ensure that the structure of the site and positioning of the content does not change to much at different resolutions. The site will be checked at the follow screen resolutions.

o 800 by 600 o 1024 by 768 o 1152 by 864

10.6 Testing Outcomes

10.6.1.1 Results of manual Testing This section will comprise of screen shots of the website providing evidence that tests from the manual test plan (Appendix A) have passed. Test1 - 4 These test are to ensure that a staff user can add venues to the system and that the staff member is returned to venue-form.php if there is a error with the data. Figure 38 show venue-form.php filled in with the information set out in the test plan. Figure 39 show the newly added venue in the list of venues. Figure 40 show the user being told that a venue of already exists.

58

http://www.freedomscientific.com/


Figure 38

Figure 39

59


Figure 40

Figure 41

Tests 5-6 This ensures that a venues details can be edited Figure 42 show the venue form with the capacity edited to 7000. Figure 43 shows the venue list wit the data edited.

60


Figure 42

Figure 43

Tests 7-9 Testing that a venue can be deleted as long as there are no concerts scheduled for the select venue. Figure 44 shows the venue list with The Cinema in Aberystwyth and Alexandra Palace in London selected for deletion. Figure 45 show that only the Cinema in Aberystwyth has been deleted because there concert scheduled there but Alexandra Palace has not been deleted because there are concerts scheduled there.

61


Figure 44

Figure 45

Tests 10 – 13 This ensures that a band can be added and that any user errors are noticed and dealt with. Figure 46 shows the band form with the band details set out in the test plan. Figure 47 shows the client side band page where the details on the band are displayed. Figure 48 shows the error displayed to the user if a required field is left null. Figure 49 shows the error displayed to the user if they try to add a band that is already in the database.

62


Figure 46

Figure 47

63


Figure 48

Figure 49

Tests 14 – 15 Ensuring that a bands details can be edited. Figure 50 shows band form for the streets where the image and alternative text fields have been edited Figure 51 show the client side band info page for the streets after the edit has been the picture and alt tag has been edited.

64


Figure 50

Figure 51

Test 16 – 18 Ensuring that a band can be deleted given the right circumstances. Figure 52 show the band list page with Green Day and Madness selected for deletion. Figure 53 shows that Green Day has been deleted but Madness has not been deleted as they have a concert.

65


Figure 52

Figure 53

Test 19 – 21 Ensuring that a city or town can be added. Figure 54 shows the city/town form with Bristol about to be added Figure 55 shows the city/town form when a user try to add a town or city that is already present in the database.

66


Figure 54

Figure 55

Tests 22 – 27 Ensuring that a concert can be added and that any user errors are dealt with. Figure 56 show the concert form with data entered as set out in the test plan. Figure 57 shows the concert in the concert list with the newly added concert. Figure 58 shows the band form when the user has been return because a require field was left null. Figure 59 shows the band form when the user has been return because the band already have a concert on the given date. Figure 60 shows the band form when the user has been returned because the venue already as a concert on the given date. Figure 61 shows the band form when the user has been returned because the release date is after the concert date.

67


Figure 56

Figure 57

68


Figure 58

Figure 59

69


Figure 60

Figure 61

Test 28 – 29 Ensuring that a concerts details can be edited. Figure 62 shows the concert form with the number of tickets edited to 2000.

70


Figure 62

Test 30 – 33 Testing that concerts can be deleted. Figure 63 show the concert list with The White Stripes concert at Alexandra Palace and the Mitchell Brothers concert at The Warehouse selected for deletion. Figure 64 shows that both of the concerts have been deleted. Figure 65 show the email received by a client when the Mitchell Brothers concert was deleted.

71


Figure 63

Test 35 Ensuring the variables used to store the database connection setting can be edited. Figure 64 shows the database controller form.

Figure 64

72


Test 36 Ensuring that the CSS can be edited with out accessing the CSS file Figure 65 shows the CSS controller page.

Figure 65

Test 37 – 42 Ensuring that emails can be sent to customers informing them of up coming events. Figure 66 show the genre email form used to send emails to all customers of a particular genre. Figure 67 shows the email received by customers relating to the genre of Ska. Figure 68 shows the band email form used to send emails to all customers of a particular band. Figure 69 shows the email received by customer relating to the band the Mitchell Brothers. Figure 70 shows the birthday email form used to send out emails informing customers what concerts are going on during their birthday month. Figure 71 shows the mail received by customers with their birthday in June.

73


Figure 66

Figure 67

74


Figure 68

Figure 69

75


Figure 70

Figure 71

Tests 43 - 49 Ensuring that someone can signup to the site to become a registered user. Figures 72 & 73 show a the signup form completed with the information in the test plan for test number 43. Figure 74 shows the page the user is sent to after submitting the form. Figure 75 shows the email received by customers to allow them to validate their account. Figure 76 shows the user validating their account. Figure 77 shows the error the user is shown if the enter an incorrect user name and password when logging in, or when a user attempts to login without validating their account.

76


Figure 72 - Showing a screen shot of the first part of the sign up form.

Figure 73 - Showing a screen shot of the second part of the sign up form.

77


Figure 74 – Showing the page displayed after the user has successfully completed the sign up

form.

Figure 75 – Showing the email the users receive to enable them to validate their account.

78


Figure 76 – Showing the user validation form.

Figure 77 – Showing the page the user is shown if they enter an incorrect user name and

password or their account has not been validated. Test 50 Ensuring a customer can edit their address details. Figure 78 shows form that allows users to edit their address details.

79


Figure 78- Screen shot showing the form for editing address details.

Test 51 Ensuring that a customer can edit their credit card details. Figure 79 shows the form that allow users to edit their credit card details.

Figure 79 – Screen shot showing the form for editing credit card details.

Test 52 Ensuring that a customer can change their password. Figure 80 shows the form that allows user to enter their password.

80


Figure 80 – Screen shot showing the form for changing passwords.

Tests 53 – 59 Ensuring the search facilities works correctly. Figure 81 shows the results of a basic search for an artist call ‘The Streets’. Figure 82 shows the results of a basic search for the town/city ‘Aberystwyth’. Figure 83 shows the results of an advanced search for town/city ‘London’, Date from ‘11th June 2006’, Date to ’24th June 2006’.

Figure 81

81


Figure 82

Figure 83

Tests 60 – 64 Ensuring that tickets can be purchased. Figure 84 show the band information page for The White Stripes. Figure 85 shows the purchase page, informing the user which account the money for the tickets will be taken from and a form to allowing the user to change the posting address. Figure 86 shows the email received by the user to confirm the booking.

82


Figure 84 – Screen shot show the band information band for The White Stripes.

Figure 85 – Screen Shot Sh

Figure 86

83


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

Figure 87 – The first version of code that sent out client verification emails.

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 = "[email protected]"; $headers ='From: [email protected];'; $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; }

84


Figure 88 – The second version of code that sent out client verification emails.

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 = "[email protected]"; $headers ='From: [email protected];'; $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); } }

This problem could be a client side problem that the emails coming from the program are being grey listed or filtered out by spam filters. Some of the users pointed out that the layout of the genre tick boxes on the client form were a little confusing so the margin around them was changed so they were spaced further apart. The program requires emails be sent out regularly which is unfortunately limited by web hosting company the amount of email that PHP scripts can send to this has caused a lot of problems during testing. The people carrying out user testing did not receive validation emails because to many people were signing up at the same time and the program tried to send all of the email. Problems where also cause when trying to test the program that keep customers up to date with event as testing took a lot of time waiting to be able to send email again. Figure # show the conversation with the web hosting support desk when beliefs that the email problem was being caused by the limiting implemented by them.

85


Figure 89

86


11 Critical Review

11.1 Methodology The methodology chosen for the project worked rather well. However a more formal use of test driven development would have aided with the implementation process. This would have been considered more if PHPUnit had been discovered earlier into the implementation process of project allowing for automated testing so that the development process is not slowed down.

11.2 PHP Because of the way PHP is designed to be used the mixing of markup and code can be difficult to separate the two. I have managed to keep the two as separate as possible but there are a few places where I feel with more time to refactor the code these problems could be solved. The Object Orientation of PHP allow for greater levels of abstraction between the different technologies. It allows developers to separate code making it easier to be read. It also allows developers to add extra functionality to a site without users of the site noticing. My knowledge of the programming language and confidence programming it has grown exponentially during the course of this project and during development I discovered a lot of functions that I did not know about, there were a number of functions that had no place for in this project but hopefully I will get a chance to experiment with tem very soon.

11.3 CSS CSS layout required a large amount of research and experimentation, but overall it was well worth the effort, as CSS layout allows the programmer much more control of the site layout than tables do, such as overlapping of elements. A lot of the problems with using CSS layout are due to the different ways that web browsers interact with the code . This make developing a site using CSS layout an interesting process fiddling with different settings until the page looks right in all web browsers. The use of PHP within the CSS file is a very nice way of allowing a user with no web development experience to change the look of their site quickly and with little fuss.

11.4 Security My knowledge of Internet security issues has greatly improved since start this project. Before I started this project I had a very limited knowledge the issues that were involved with ensuring the security of a websites, my knowledge was limited to know of SQL injection and Phishing. I found the research and implementation of security feature the most stimulating throughout the project and plan on furthering my knowledge in this field as well as web server security. I feel the security of the site is quite strong however it is no where near completely secure. I would have liked to have been able to implement the project using Secure Socket Layers.

87


11.5 Accessibility The project is missing a non-visual CAPTCHA, this would be one of the main things that should be added to ensure the client side of the site was deemed accessible. Unfortunately there was not time to add a non-visual CAPTCHA. This project has increased my experience with creating accessible web pages and has understanding of web accessibility and how different users interact with that same website. It would have been nice to be able to user testing with partially sighted and blind users to get some insight into how they navigate a site and what they find annoying to improve my understanding of how to make future work as accessible as possible.

11.6 Testing The testing of PHP programs is a very difficult process. It was found that user testing found more errors than the traditional manual testing done by the developers. If the project was to be started again the methodologies used would include formal Test Driven Development using a test framework such as PHPUnit. The testing would also include user testing upon reaching major milestones throughout development. Another problem the user testing highlight was how difficult it is to replicate errors that occurred while the user was going though their testing. It was felt that the best way to carry out user testing was on a one to one basis so that the developer could record what the user does to assist in identifying where problems occur and how they can be fixed. Unfortunately there were no users with visual disabilities which would have been very useful for testing how accessible the website is rather than just relying on checking the site against the WAI checklist and using online testing programs. It was also discovered that use of the access software IBM homepage reader and JAWS for window required a lot of user expertise and also had a steep learning curve even for completing the most basic of tasks. This meant that the browser testing with these pieces of software was very limited Security Testing could not be carried out on the program as testing much of the security of such a program requires knowledge of hacking practises that were not available. Large companies that implement systems like this that do require security testing hire White Hat Hackers (hackers who use their skill for good ) to test how secure their program is.

11.7 Improvements There are a few ways that it is felt the system could be improved with more time or in a second version. These improvements include; A calendar of events allowing users to browse all the events in a given month quickly. This feature has been added to some of the existing online ticket sales systems during the implementation of this project. It would have been nice to have been able to have the system to connect an online payment solution. I would learn how to set up a web server properly so that I had more control over the features and technology I would have at my disposal. Having a dedicated server would have sped up the implementation stage of the project and allow me to implement feature that such as SSL and database transactions that would have been implemented had the chance to use them been there.

88


The CSS controller page could be improved by implementing a colour picker so that I was not left to the user to work out the hexadecimal value of the colour they want. The problem with the header image could have been solved by using PHP to dynamically create the image when the month changed or the background colour of the header was changed using CSS controller page.

11.8 Overall Using a web hosting service can be very restrictive as much of this document shows. A large percentage of problems occurring during development were caused by the web hosting service not supporting a technology or settings under the control of the web hosting company. The only way of guaranteeing that a program can make use of any functionality that a system will require not to use a web hosting service, but instead set up a web server dedicated to running any programmes written. This allows program developers to install or allow use of any functionality they require for their program to work. Another advantage of not using a web hosting service is the program could have been made more portable if it was originally written on a dedicated server. However, running your own web server for such a site as this requires a lot of knowledge on keeping a server freely available to the public secure. This has prompted my to put more effort in to learn how to setup and administer a web server for any future work to ensure that programs are not compromised by what the web hosting company do and do not offer. The project has introduced me to a number of aspects for programming for the Internet including: how to write program so that it is as secure as possible. I found the research about the security issues and how to protect a website very interesting. My only regrets about the security of the site was not being able to use SSL and I wish I had researched more security issues before starting coding as this would have saved a lot of time.

89


12 Bibliography [1] British Standards Institute, 2005, PAS 78 Guide to Good Practice in Commissioning Accessible Websites [2] H. M. Deitel, P. J. Deitel & Tem. R. Nieto, 2002, Internet & World Wide Web How to Program, Pearson Education – Prentice Hall, United States of America [3] Elizabeth Castro, 2003, HTML for the World Wide Web with XHTML and CSS, Peachpit Press, United States of America [4] Wendy Chisholm, Gregg Vanderheiden & Ian Jacobs, 1999, Web Content Accessibility Guildlines 1.0, http://www.w3.org/TR/WAI-WEBCONTENT/ (Date Accessed: 14/02/06) [5] Wendy Chisholm, Gregg Vanderheiden & Ian Jacobs, 1199, Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0, http://www.w3.org/TR/WAI-WEBCONTENT/full-checklist.html (Date Accessed: 14/02/06) [6] Christine Faulkner 1998, The Essence of Human-Computer Interaction, Prentice Hall, England [7] Disability Discrimination act , 1995, Disability Discrimination act, http://www.opsi.gov.uk/acts/acts1995/1995050.htm (Date accessed: 07/03/06) [8] Jeremiah Grossman – WhiteHat Security, (2001), Web Application Security, http://www.whitehatsec.com/presentations/Black_Hat_Europe_2001/Black_Hat_Europe2001_Presentation.ppt (Date Accessed: 02/04/06) 9] Jeremiah Grossman – WASC (Web Application Security Consortium), 2004, WASC Activities and U.S. Web Application Security Trends, http://www.whitehatsec.com/presentations/WASC_WASF_1.02.pdf (Date Accessed: 02/04/06) 10] Matt May - W3C, 2005, Inaccessibility of CAPTCHA http://www.w3.org/TR/turingtest/ (Date Access: 21/03/06) [11] Eric A Meyer, 2004, Cascading Style Sheets The Definitive Guide, O’Reilly 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, O’Reilly 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

http://www.w3.org/TR/WAI-WEBCONTENT/

http://www.w3.org/TR/WAI-WEBCONTENT/full-checklist.html

http://www.w3.org/TR/WAI-WEBCONTENT/full-checklist.html

http://www.opsi.gov.uk/acts/acts1995/1995050.htm

http://www.whitehatsec.com/presentations/Black_Hat_Europe_2001/Black_Hat_Europe2001_Presentation.ppt

http://www.whitehatsec.com/presentations/Black_Hat_Europe_2001/Black_Hat_Europe2001_Presentation.ppt

http://www.whitehatsec.com/presentations/WASC_WASF_1.02.pdf

http://www.w3.org/TR/turingtest/


[17] Matt Zandstra, 2004, PHP 5 Objects, Patterns, and Practise, Apress, United States of America

91


13 Appendix A Manual Testing – Test plan Test Number

Functional Requirement

Testing Expected Outcome

Actual Outcome

1 FR5 A venue can be added to the system Venue Name – Art Centre Town/City – Aberystwyth Capacity – 2500

A staff user should be able to add information about a concert venue into the system.

Test Passed – Staff users are able to add venues to the system

2 FR5 Only administrators and data entry staff can add venues

Only staff set as administrators and data entry staff should be able to gain access to add venues.

Test Passed – only administrators and data entry staff can add venues.

3 FR5, FR6 When a venue is added all required fields are filled in.

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.

Tested Passed – if some of the required fields are left blank the venue is not added and the staff user is informed so.

4 FR5, FR6 When a venue is added there are no other venues with the same name in the same city or town

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.

Test Passed – a venue with the same name and town/city as a venue in the database cannot be added.

5 FR6 That a venue information can be updated

A staff user should be able to update information about a concert venue that exists in the system.

Test Passed Venue information can be edited.

6 FR6 Only administrators and data entry staff can edit venues

Only staff set as administrators and data entry staff should be able to gain

Test passed – only administrators and data entry staff can edit

92


access to edit venues.

venues

7 FR6 A venue can be removed

A staff user should be able to remove a concert venue from the system.

Test Passed – Venues can be deleted.

8 FR6 A venue can not be removed if there is a concert scheduled there.

A venue should not be deleted if there is a concerts scheduled in the venues

Test Passed – A venue is not deleted if there is a concert scheduled there.

9 FR6 Only administrators and data entry staff can delete venues

Only staff set as administrators and data entry staff should be able to gain access to delete venues.

Test passed - Only administrators and data entry staff can delete venues

10 FR5 A band can be added. Name – The Streets Genre – Hip Hop Website www.the-streets.co.uk Description - Picture -

A staff/admin user should be able to add information about a band to the system.

Test Passed – A band can be added to the database.

11 FR5 Only administrators and data entry staff can add bands

Only staff set as administrators and data entry staff should be able to gain access to add bands.

Test passed - Only administrators and data entry staff can add bands

12 FR5, FR6 All require fields must be completed for a band to be added

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.

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.

13 FR5, FR6 A band cannot be added with the same name as another band.

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.

Test Passed – A band cannot be added if there is a band in the database with the same name.

14 FR6 A band’s A staff user Test Passed - A

93


information can be updated

should be able to update a band’s information that exists on the system.

bands information can be updated

15 FR6 Only administrators and data entry staff can edit bands

Only staff set as administrators and data entry staff should be able to gain access to edit bands.

Test Passed - Only administrators and data entry staff can edit bands

16 FR6 A band can be removed

A staff user should be able to remove a band from the system.

Test Passed – a band can be deleted.

17 FR6 A band will not be removed if they have a concert scheduled

A band should not be deleted if the band has concerts scheduled.

Test Passed - A band will not be removed if they have a concert scheduled

18 FR6 Only administrators and data entry staff can delete bands

Only staff set as administrators and data entry staff should be able to gain access to delete bands.

Test Passed - Only administrators and data entry staff can delete bands

19 FR5 A city / town can be added. City/town: Bristol

A staff user should be able to add information about a town or a city into the system.

Test Passed – a city/town can be added.

20 FR5 When a city / town is added all require fields have been filled in

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.

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

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.

Test Passed –a town or city can not be added twice.

22 FR5 A concert can be added

A staff user should be able to

Test Passed – A concert can be

94


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

add information about a concert into the system.

added.

23 FR5 Only administrators and data entry staff can add concerts

Only staff set as administrators and data entry staff should be able to gain access to add concerts.

Test Passed - Only administrators and data entry staff can add concerts

24 FR5, FR6 All required fields must be completed for a concert to be added

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.

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.

25 FR6, FR6 A concert venue cannot have two concerts booked on the same date.

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.

Test Passed – A concert cannot be added if there is already a booking for that venue on that day.

26 FR5, FR6 A band cannot have two concerts booked on the same day.

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.

Test Passed – a concert can not be added if the band already have a concert on the given day.

27 FR5, FR6 The concert date cannot be after the release date for the tickets

If a staff user tries to add a concert with the ticket release date set after the

Test Passed – if the release date is after the concert date the concert will not

95


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.

28 FR6 That a concert’s information can be updated

A staff user should be able to update information about a concert that exists in the system.

Test Passed – A concert can be updated.

29 FR6 Only administrators and data entry staff can edit concerts

Only staff set as administrators and data entry staff should be able to gain access to edit concerts.

Test Passed - Only administrators and data entry staff can edit concerts

30 FR6 That a concert’s information can be deleted

A staff user should be able to delete concert that exists in the system.

Test Passed – A concert can be deleted.

31 FR6 Only administrators and data entry staff can edit concerts

Only staff set as administrators and data entry staff should be able to gain access to delete concerts.

32 FR6 That if a concert has been released and it is deleted client with tickets booked are sent an email

When a concert is delete clients are informed of its cancellation

Test passed if a concert is cancelled clients are email when it is deleted.

33 FR6 Test that when concert with bookings is deleted the bookings are deleted too.

When a concert is delete any booking that were made for it should be deleted to keep referential integrity

Test Passed – When a concert is delete any booking for that concert are also deleted.

34 Staff cannot buy tickets.

A user logged in as staff should not be able to buy tickets.

Test Passed – A member of staff could not access the pages that allow clients to purchase tickets

35 FR10 Database settings can be edited

An administrator should be able to

Test Passed – Administrators

96


change database connection settings from the websites

can change database settings and this can only be done by Administrators

36 FR10 That style settings can be changed

A administrator should be able to change style settings from the websites

Test Passed - Administrators can change style settings and this can only be done by Administrators

37 FR7 That an email can be sent out updating fans of a particular genre

Staff should be able to send out emails to fans of a particular genre.

Test Passed – Staff can send out emails to fans of a particular genre

38 FR7 That genre update emails only got to fans of the selected genre.

Only fans of a particular genre should receive genre update emails

Test Passed – Only fans of a genre receive update emails for that genre.

39 FR7 That an email can be sent out regarding a selected band.

Staff should be able to send out emails updating people of a band’s concerts.

Test Passed – Staff can send out email with information about a band’s concerts.

40 FR7 That a client only receives an emails when they have shown an interest in the genre of which the band is in.

Client should only receive emails about bands within the genres they selected when they signed up.

Test Passed – Clients only receive emails about bands within the genre they registered an interest in.

41 FR7 Test that staff can send out birthday emails.

Staff can send out emails about a month’s events and all clients with birthdays in that month receive the email.

Test Passed – staff can send out birthday emails.

42 FR7 That only clients with birthdays in the selected month receive a birthday email.

Only clients with birthdays in the selected month should receive an email.

Test Passed – only clients with birthdays within the selected month receive birthday emails.

43 FR2 Test that it is possible for non-members of the site to sign up to become a member. First Name – Mark

Upon completion of the client form the user should be registered with the site.

Test passed – users are able to sign up for the site using the client form.

97


Surname – Bradley Email Address – [email protected] of Birth – 11 June 1984 Address Line 1 – 108D Address Line 2 – Pentre Jane Morgan Town – Aberystwyth County – Ceredigion Postcode – SY23 3TG Telephone Number – 01322441848 User Name – mdb2 Password – password Genres Brit pop, Hip Hop, Indie, Ska, Rock and Roll Card Type: Card B Card Number 0123987456 Start Date: 07/2003 Expiry Date: 10/2008 Security Code 951

44 FR2 All required fields must be filled in

If a user leaves a required field blank they should be sent back to the client form and informed of the error.

45 FR2, FR4 Test that a client is not able to sign up with out entering the correct CAPTCHA string.

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 Test that a client is not able to sign up without the password in the password and re-enter password fields matching.

The client should not be able to sign up in the site if the both passwords do not match.

47 FR3 Once someone has Once a client Test Passed –

98

mailto:[email protected]


registered to become a member they are sent a customer validation email

registers with the site a validation email should be sent to their given email address that will send them a link to validation page

Users receive a validation email upon completing the signing up process

48 FR3 A customer is validated upon following the link to validation page.

The link on the validation email will link to the validation page with the clients ‘clientNum’ being used to uniquely identify the user.

Test Passed – The email includes a link that allows the user to validate their account

49 FR3 A customer is unable to log in to their account until they have validated their account

Before the user validates their account they should not be able to log in to the website. Once they have registered they should be able to log in to the site.

Test Passed a user is not able to log in without their account being verified.

50 FR9 That a client user can edit their address details once they have signed in.

A client should be able to edit their address details once they have logged into the website.

Test passed – Users are able to change their address details once they have logged into the site.

41 FR9 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.

Test Passed - Users are able to change their credit card details once they have logged into the site.

52 FR9 That a client user can change their password once they have signed in.

A client should be able to edit their password once they have logged into the website.

Test Passed - Users are able to change their password once they have logged into the site.

53 FR8 Test that the basic search works when searching for an artist returns correct results.

The user should be shown all of the concerts for the band entered in the test box

Test Passed – The user was shown a list of all concerts for the band entered in the text box.

54 FR8 Test that the basic The user should Test Passed – the

99


Search for a city returns correct results.

be shown all of the concerts in the town selected in the drop down menu.

user was shown a list of all concerts in the selected city.

55 FR8 Test that the basic search for an artist and a city returns the correct results.

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.

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.

56 FR8 Test that the advanced search returns the correct results when searching by artist or genre

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.

Test Passed – the artist and genre search works and brings back the correct results.

57 FR8 Test that the advanced search returns the correct results when searching by city/town or venue

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

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.

The date search allows to search for concerts on a given date or for concert in-between a set of dates.

Test Passed – The date search works correctly and bring back the correct results.

59 FR8 Test that if a search yields no results the user is informed so and not just shown a blank page.

If a search returns not results rather than leaving the page blank the search should be informed that their search found no concerts

Test Passed – if a search finds no results the user is informed so.

60 FR1 Test that a buy tickets link will only appear if

When tickets are not sold out and release clients

Test Passed – if there are tickets available clients

100


tickets are available should be able to follow a link to tickets.php to start the purchasing process.

are able to purchase them.

61 FR1 Test that if tickets are sold out the client is informed so.

If tickets are sold out client should not be able to purchase tickets

Test Passed - If tickets are sold out the link to tickets.php is read with plain text saying ‘sold out’.

62 FR1 Test that if tickets have not been released yet the client is informed so

Client should not be able to buy ticket that have not yet been released

Test Passed – there is no link for concert tickets until the tickets are released.

93 FR1 Test that the program totals up the price and informs the client of the total and the account the money will be taken from

On purchase.php the client should be told the total price of there purchase

Test Passed – The program works out the correct total for the purchase

64 FR12 WAI Level A compliance

Web pages should pass the WAI level A checklist requirements,

Test Passed See appendix # for completed checklist

65 FR12 WAI Level AA Compliance

Web pages should pass the WAI level AA checklist requirements

Test Passed See appendix # for completed checklist

101


14 Appendix B - results of user testing Web Browser (includes any access technology used, i.e. Screen Readers): IE 7 and Mozilla 1,5 Age: 44 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



Took about 2 mins to sign up.


email did not arrive!


Done


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

UT8 Advanced Search – Using this form complete the searching set out below. Search 1: Genre – Hip Hop City/Town: Birmingham Search 2: Venue – Alexandra Palace Date from – 11th June 2006 Date to – 21 June 2006 Search 3:

Mitchell Brothers The Streets

102


Artist - Steps Venue – The Playhouse - Erith

UT9 Locate a band using Genres List – Using the genre list find a band’s information page.

OK worked (Artic Monkeys)

UT10 Locate a band using Bands List – using the band list page find a band’s information page

OK worked (Artic Monkeys)


Tried to buy tickets for the killers, dumped back to main screen

UT12 Log out – finally log out the system Any other comments on the site?

103


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



Ok Easy to follow instructions


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


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?


Used this to locate Ska, Madness got details of band

104


on screen UT10 Locate a band using Bands List – using the band

list page find a band’s information page Used list, to locate Red Hot Chilly Peppers


Made a purchase for Madness tickets.

UT12 Log out – finally log out the system 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


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



ok


The link that you get sent inst one you can click on you have to cut and paste it


ok


Changed, but wouldn’t it be good if once you clicked on change it said changes have been successful?


Same as above, casue you don’t know if its changed it



Don’t like the date format


Fine Wouldn’t the venues be better in alphabetical order?

106



ok

UT10 Locate a band using Bands List – using the band list page find a band’s information page

ok


ok

UT12 Log out – finally log out the system ok Any other comments on the site?

107


15 Appendix C - WAI The three tables below are the WAI checklists for ensuring your site is accessible take from []

15.1.1.1.1 Priority 1 checkpoints In General (Priority 1) Yes No N/A

1.1 Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ascii art, frames, 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) Yes No N/A

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) Yes No N/A5.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) Yes No N/A12.1 Title each frame to facilitate frame identification and navigation.

And if you use applets and scripts (Priority 1) Yes No N/A6.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) Yes No N/A1.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

108


the visual track) with the presentation. And if all else fails (Priority 1) Yes No N/A

11.4 If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page.


2.2 Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when 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


And if you use tables (Priority 2) Yes No N/A5.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) Yes No N/A12.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) Yes No N/A10.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) Yes No N/A

6.4 For scripts and applets, ensure that event handlers are input device-independent.

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.


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


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) Yes No N/A

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) Yes No N/A5.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) Yes No N/A10.4 Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas.

111

Online Ticket Booking System - · PDF fileOnline Ticket Sales System ... The project was to...

Documents

Transcript of Online Ticket Booking System - · PDF fileOnline Ticket Sales System ... The project was to...