Web Site for Secure Computing ** ** Dov Labi

** Web Site for Secure Computing **
** Dov Labi **
** Information Systems **
** Session 2003/2004 **
The candidate confirms that the work submitted is their own and the appropriate credit has been given
where reference has been made to the work of others.
I understand that failure to attribute material which is obtained from another source may be considered
as plagiarism.
(Signature of student)
Summary
Every module in the School of Computing requires a website. Therefore, when the new module,
Secure Computing was introduced such a website had to be developed. In addition, this module wanted
to attract other users, so a website for users that are not members of the School of Computing was required. Furthermore, the website would provide a private access area for lecturers and tutors connecting
from other universities.
The main objective of this project is to create these websites. This report delivers the stages that
were taken to develop the sites.
i
Acknowledgements
I would like to thank my project supervisor Nick Efford for his continued support and help throughout the duration of this project.
I would also like to thank my assessor Bill Whyte for assisting me at time of need.
Special thanks goes to my dear friends, Robert Woolfson, Kieran Allen, Jacqueline Leech, Aron
Cohen and all those who stood by me and helped me throughout the duration of this project.
I would also like to thank my lovely girlfriend, Jordana Rashman, who managed to put up with me
through good and bad and was there for me when I needed her most - Thank You.
Most of all I’d like to thank my dear parents for always being supportive and without them, none of
this would have been possible.
Finally, I would like to thank McCoys Crisps for sustaining me through all those long nights in the
labs - Big up McCoys!
ii
Contents
1
2
Introduction
1
1.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.1.1
1.1.2
Problem Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Project Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1
1.1.3
Minimum Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.1.4
1.1.5
Project Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Project Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2
Background Research
2.1 Methodologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
4
2.2
2.1.1
Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.1.2
2.1.3
Waterfall Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Structured Systems Analysis and Design Method (SSADM) . . . . . . . . . .
4
5
2.1.4 Choice of Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Web Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
5
2.2.1
Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2.1.1
2.2.1.2
Web Browsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Javascript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
6
2.2.1.3
Cascading Style Sheets . . . . . . . . . . . . . . . . . . . . . . . .
6
Server-Side Includes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Server-Side Scripting Languages . . . . . . . . . . . . . . . . . . . . . . . . .
7
7
2.2.3.1
2.2.3.2
ASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
7
2.2.3.3
PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2.3.4 Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
8
2.2.4.1
IIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2.4.2 Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
9
2.2.2
2.2.3
2.2.4
2.2.5
iii
2.2.6
2.2.7
3
4
2.2.5.1
MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2.5.2
SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2.5.3 Postgresql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
9
2.2.6.1
2.2.6.2
Screen Real Estate . . . . . . . . . . . . . . . . . . . . . . . . . . .
Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
10
2.2.6.3
Screen Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.2.6.4
2.2.6.5
Download Time . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
10
2.2.6.6
Colours
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
Accessibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
Analysis
12
3.1
12
12
Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 The Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1.1
Students . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.1.1.2
3.1.1.3
Public Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tutors/Lecturers . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
13
3.1.1.4
3.1.1.5
Evaluation of module websites . . . . . . . . . . . . . . . . . . . .
Requirement Capture for internal site . . . . . . . . . . . . . . . . .
14
14
3.1.1.6
Requirement Capture for external site . . . . . . . . . . . . . . . . .
14
Design
4.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
16
4.1.1
Choice of Development Languages . . . . . . . . . . . . . . . . . . . . . . .
16
4.1.2
Choosing the Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.2.1 Colors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
17
4.1.2.2
4.1.2.3
Building the prototype for the internal site . . . . . . . . . . . . . .
External Site Layout . . . . . . . . . . . . . . . . . . . . . . . . . .
17
19
4.1.2.4
Site Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
4.1.3
4.1.4
Site Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Information Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
20
4.1.5
Choice of Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.5.1 Database design for Internal Site . . . . . . . . . . . . . . . . . . .
21
22
4.1.5.2
Database design for External Site . . . . . . . . . . . . . . . . . . .
22
4.1.5.3
Database design for ‘Site Update’ function . . . . . . . . . . . . . .
25
iv
5
Implementation
27
5.1
Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
5.1.1
5.1.2
Implementation of the Database . . . . . . . . . . . . . . . . . . . . . . . . .
connection.php . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
28
5.1.3
5.1.4
JavaScript Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Site Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
29
5.1.5
Implementation of the Internal Site . . . . . . . . . . . . . . . . . . . . . . .
30
5.1.5.1
5.1.5.2
Random Quotes . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Online Resources . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
30
Implementation of the External Site . . . . . . . . . . . . . . . . . . . . . . .
31
5.1.6.1
5.1.6.2
Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
34
5.1.6.3
5.1.6.4
User Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Members Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
36
5.1.6.5
Change password . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
5.1.6.6 Member Downloads . . . . . . . . . . . . . . . . . . . . . . . . . .
Site Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
39
5.1.7.1
File Upload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
Viewing/Editing tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
40
Testing
6.1 Testing and Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
42
5.1.6
5.1.7
5.1.8
5.1.9
6
6.1.1
6.2
Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
6.1.1.1
6.1.1.2
Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
System Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
42
6.1.1.3
6.1.1.4
Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Browser Compatibility . . . . . . . . . . . . . . . . . . . . . . . .
43
43
6.1.1.5
Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
6.1.1.6
6.1.1.7
Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
44
6.1.1.8
Administration Section . . . . . . . . . . . . . . . . . . . . . . . .
44
Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
45
6.2.1.1
6.2.1.2
Evaluation Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evaluation of Minimum Requirements . . . . . . . . . . . . . . . .
45
45
6.2.1.3
Exceeding the minimum requirements . . . . . . . . . . . . . . . .
46
6.2.1.4
6.2.1.5
Selection of a good methodology . . . . . . . . . . . . . . . . . . .
Satisfactory Implementation . . . . . . . . . . . . . . . . . . . . . .
48
48
v
6.2.2
6.2.1.6
Good Design and User Satisfaction . . . . . . . . . . . . . . . . . .
48
6.2.1.7
Solution to the problem . . . . . . . . . . . . . . . . . . . . . . . .
49
Further Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
Bibliography
51
7
Appendix A
54
8
Appendix B
56
9
Appendix C
57
10 Appendix D
64
11 Appendix E
68
12 Appendix F
70
13 Appendix G
72
14 Appendix H
73
15 Appendix I
75
vi
Chapter 1
Introduction
1.1 Introduction
This section will briefly give an overview of the project, what it was about, its aim and minimum
requirements.
1.1.1 Problem Definition
In 2004 the School of Computing (SoC) in the University of Leeds introduced a new module, the Secure
Computing module (SY32). As with all new modules in the SoC, this module needed an online system
for students taking the module to interact with in order to check the modules latest updates, download
coursework, view lecture slides etc. This module also required an external system to be developed,
which would allow for users that are not part of the SoC, such as A-Level students, to learn more about
the module and what is currently being taught in the Secure Computing module. The external system
also needed to have a ‘secure, private area’ where lecturers or tutors can view notes, lectures, or have
access to specific downloads such as coursework or coursework answers.
It was also necessary to ensure that the system would be cross-browser compatible, which would assist
users that use different operating systems, such as Microsoft Windows, or Linux.
1.1.2 Project Aim
The aim of this project as stated in the project details form was ‘To produce a secure website for the
Secure Computing module”.
1
1.1.3 Minimum Requirements
The below requirements were obtained after a discussion with my supervisor:
Requirement 1: Internal website accessible only to students
Requirement 2: External website for external users (non-students) with overlapping content.
Requirement 3: Cross-browser compatibility
Requirement 4: Security, with user name and password log in function.
Requirement 5: User feedback
1.1.4 Project Objectives
In addition to the project’s minimum requirements, It was necessary to set specific objectives, which
will later be evaluated at the end of this project. They are defined below:
To develop two websites, for students within the SoC taking the Secure Computing module and
for public users.
To select a methodology which will most fit the development of this project
Implement a good design for the two web sites.
Perform a good implementation such that future developers can understand and make use of the
written code.
1.1.5 Project Planning
Appendix B has the initial Gantts chart that was originally planned when this project began. The first
‘internal’ site was the main priority for this project as the Secure Computing module didn’t have an
existing website. The site had to be developed as quickly as possible, as the students taking the module
had no way to interact with the module content or download lecture slides and coursework. The plan is
documented below:
03.11.03 —24.11.03: Background Research
24.11.03 —08.12.03: Analysis, requirements gathering
08.12.03 —15.12.03: Mid Project Report
15.12.03 —16.02.04: Design of the two sites (However, a month was left here for exam revision).
16.02.04 —08.03.04: Implementation of sites
2
08.03.04 —29.03.04: Testing and Evaluation (Some of this time was used for the write-up as it
was the Easter break)
29.03.04 —28.04.04: Write up report and make necessary changes
3
Chapter 2
Background Research
2.1 Methodologies
Methodologies are commonly used when attempting to develop a successful project. A methodology
ensures that a system developer will use a “specified sequence of tasks” [Fiduk, Kleinfeldt, Kosarchyn,
and Perez, 1990]. In order to develop a successful system, it is essential to follow this sequence. Some
methodologies will be discussed in this section.
2.1.1 Prototyping
The Prototyping methodology is an iterative methodology used during the system development process.
It is widely known that if an error was to occur in the early stages of the development process, it
would be highly costly if the error were to be noticed later in the development [Mason and Carey,
1983], thus it is important to spot the error before the finalisation of the system. Consequently, the
Prototyping methodology was developed to help bring about a solution to this problem. Lantz [1987]
states that the prototyping methodology enables the users to “play” with a system and modify it before
it is implemented. The goal of the Prototyping methodology is “for developers to discover critical
properties of their product before making final decisions” [Purtilo, Larson, and Clark, 1991] and thus
ensuring that less errors will occur.
2.1.2 Waterfall Model
The waterfall model is another system development methodology. The Waterfall model is a very common model within the Systems Development Life Cycle (SDLC). When describing software development according to the waterfall model, the process can be seen as a ”fixed sequence”. When viewed
according to this model, each step of development is considered self-contained and irreversible [Raccoon, 1997], thus, programmers should be cautious of completing a stage before moving on to the next.
4
The stages of the waterfall model are expressed in Strong’s (1992) paper where he mentions that the
waterfall model consists of, Analysis, Design, Implementation and Testing [Strong, 1992].
The model however “fails to account for change and other evolutionary aspects of projects” [Raccoon,
1997], this refers to things such a debugging and maintenance, therefore, once a step has been committed, the waterfall model doesn’t allow any ’stepping back’.
2.1.3 Structured systems analysis and design method (SSADM)
SSADM is divided into seven stages: Feasibility study, Investigation of current environment, Business
system options, Definition of requirements, Technical system options, Logical design and Physical design. SSADM has been described as primarily focused on teamwork in projects of relatively large scope.
The methodology was therefore rejected as it was not appropriate for the scope of this project. Another
factor discovered was that the methodology does not include system maintenance. This is an obvious
problem for any system for which the intention is for ongoing usage [Avison and Fitzgerald, 2002].
2.1.4 Choice of Methodology
The methodology that most fitted this project was the Prototyping methodology, as this development
would need to have iterative stages. The methodology was strictly followed throughout the whole development process.
2.2 Web Applications
The main purpose of all web applications is to aid the completion of one or more tasks over a network.
A web application comprises of various programs that assist in handling different problems, such as
dealing with requests from the client and helping the administrator update a web page. As these applications need to exchange data between one another, Gray [2001] notes that they “need to be deployed
as a group along with necessary static HTML pages”.
Client/Server computing divides a computer application into three basic components: a client, a server
and a network that connects the client to the server. The client and the server are both computers with
varying degrees of processing power and both the client and the server computers share the computing
workload to get the job done [Lowe, 1995].
2.2.1 Client
The user side of the web application, widely known as the client, makes use of various different technologies; these technologies include a Web Browser and Client-Side Scripting, such as JavaScript and
CSS.
5
2.2.1.1
Web Browsers
The web browser is the key player when displaying any form of client side scripting, such as HTML
and JavaScript. It allows for these technologies “to be integrated into a single system” [Boroni, Goosey,
Grinder, and Ross, 1998], meaning that the browser has the ability to accept many different web scripting
languages and display them in a in a user-readable format. However, there are many Web Browsers that
are no longer in use, w3schools.com [2004] displays a table of the most widely used browsers in figure
2.1:
Figure 2.1: Browser Statistics
2.2.1.2
Javascript
As mentioned above, JavaScript is a client-side scripting language. One of the main benefits of clientside scripting is offloading some of the server’s work onto the client [Gray, 2001]. It does this by
executing code on the client when a page has finished loading or when a user clicks on an HTML
element. One of the main benefits of JavaScript is that it allows for the web page developer to validate
a form without adding extra load onto the server [Gray, 2001]. Even though this can be bypassed, it
wouldn’t cause any security breach as it would only be used to validate that a user has entered details in
all the required fields.
2.2.1.3
Cascading Style Sheets
Cascading Style sheets, more commonly known as CSS describe “how documents are to be presented”
[Lie and Saarela, 1999]. These style sheets manage to simplify web page administration, as one style
sheet “can describe many documents” [Lie and Saarela, 1999]. Style Sheets can set rules to selected
HTML elements and define a ’look and feel’ to the web page. Before Style Sheets were introduced,
web developers had to insert the ’look and feel’ of a web page into every necessary HTML tag, thus the
development of style sheets allows for a web developers work to be cut down immensely.
6
2.2.2 Server-Side Includes
Apache.org [2004] defines Server Side Includes as “directives that are placed in HTML pages, and
evaluated on the server while the pages are being served”. Server Side Includes, also known as SSI, is a
method used when trying to include a web page with another page. This saves the web page developer
from having to re-write repetitive code.
2.2.3 Server-Side Scripting Languages
Because this project is web based and has the need for user-interaction, there is the need to select a
Server-side scripting language. The point of server side scripting is to “tie together the user interface
presented to the user and the back end of the application or server system and database used by the
application” [Gesker, 2001]. Although there are others, several different languages that will be discussed
are ASP, PHP, CGI/Perl and JSP [Chung and McLane, 2002].
2.2.3.1
ASP
When developing a script using Microsoft’s Active Server Page (ASP), there are various languages that
the script could be written in, such as JavaScript or Perl. However, the most common language that ASP
scripts are written in is VBScript [Gray, 2001]. As Microsoft developed ASP, its main functionality
resides on Microsoft machines with Microsoft Web Servers it is therefore platform dependant.
2.2.3.2
JSP
JSP, also known as Java Server Pages, is Suns attempt to enter the world of server-side programming.
JSP is controlled by a servlet engine that processes the Java code. A server-side component known
as a JSP container takes these JSP and translates them into Java servlets, which are then processed
through the servlet engine [Merriam-Powel, 2004]. An advantage of JSP is that is it very powerful
[Merriam-Powel, 2004]. However, the requirement of the servlet engine makes it difficult to install
[Merriam-Powel, 2004]. Furthermore, Java was not designed for web-page development. Therefore it
has some disadvantages when trying to do some specific web related functions, for example, connecting
to a database can be extremely tedious, as it requires numerous steps such as registering drivers for the
database and creating a URL object pointing to the server [Merriam-Powel, 2004].
2.2.3.3
PHP
PHP is a server-side language that allows developers to build web applications. PHP’s features can easily
be compared to Microsoft’s ASP. Both PHP and ASP are scripting tools that allow HTML and code to
be mixed in the same file. Both languages allow for a database driven website to be built. However,
unlike ASP, PHP is open source and cross-platform [Knudsen, 1999]. PHP can run on Windows NT
under Microsoft’s IIS web server or on any UNIX variant as an Apache module or CGI it can even
7
run on an Apache Server sitting on a windows platform [Knudsen, 1999]. PHP is widely used, and
as Knudsen [1999] claims it will continue, ”to grow in popularity”. Other developers, such as Riddell
[2000] express the view that “PHP’s future is bright”
2.2.3.4
Perl
Perl is yet another server-side scripting language, however, unlike PHP it wasn’t designed for web
usage [php.net, 2004]. As it wasn’t initially designed for web programming, it runs fairly slower than
other scripting languages [Utah, 2004]. Perl is also a ‘cross platform programming language’ and Open
Source software [perl.org, 2004]. During his analysis on Perl, Gesker [2001] found Perl to be a complex
solution for attaching web pages to a database back end.
2.2.4 Server
When a client tries to access a web page, the client’s browsers needs to be able to interact with a ‘web
server’. A web server is hardware and software used to manage client requests (usually from a web
browser) and to return documents (usually web pages) to the client. It is the place where the web page
lives. There are two major web server applications available: Apache and IIS.
2.2.4.1
IIS
IIS (Internet Information Services) is the Microsoft Windows Web server that allows you to publish
information on your intranet or over the Internet. Microsoft’s Active Server Page (ASP) technology
and the IIS application together represent an alternative basis for server-side development in windows
environment. “A problem with IIS is that after its install, the IIS server, a file transfer server and a mail
handler server become automatically started services” [Gray, 2001], therefore, this can increase your
exposure to hackers who will exploit any weaknesses that exist in ISS versions that do not incorporate
the latest security patches. In addition, the IIS server is only available on Microsoft platforms.
2.2.4.2
Apache
Apache is yet another Web Server, however, unlike Microsoft’s IIS Web Server it is open source and is
cross-platform compatible. Thus making it the most widely used Web Server on the Internet [Mockus,
Fielding, and Herbsleb, 2000].
The Apache web server is scalable. It can be configured so that it can run on a typical home/office
PC, to provide access to a small company’s web site [Gray, 2001]. However, Apache is a lot harder to
set up than windows ISS, it requires a lot more configuration and isn’t as simple as the ’Add/Remove
Programs’ function which is used to add IIS in windows. This was substantiated by the fact that the
Apache installation was found to be more complex due to its configuration file. Even though the Apache
Server installation was more difficult than that of ISS, It was chosen above IIS due to its wider platform
facility and the fact that it is open-source. The system would be developed on my laptop.
8
2.2.5 Databases
In order to create a web site that interacts with the user, the use of a database was required. This
is due to a “significant amount of information on the Web [that] cannot be accessed directly through
links, but is available only as a response to a dynamically issued query to the search interface of a
database” [Gravano, Ipeirotis, and Sahami, 2003]. This means, that in order for a user to retrieve specific
information from a website, such as logging in to a members area and downloading secure files, it is
essential to have a database to control this facility.
2.2.5.1
MySQL
MySQL was developed as an open-source piece of software; it is also a lot faster than almost any current
database [Axmark and Widenius, 1999]. MySQL also requires a lot less hardware resources Kaufman
[2003], such as storage space, than other databases. It is also limited in the amount of processing power it
needs. Kaufman [2003] clearly states that you can even run “MySQL on a 64-bit processor” [Kaufman,
2003]. However, MySQL has difficulties when trying to deal with a lot of web traffic [Collaborative
Computational Project, 2004]. Although this is true, it was assumed that hundreds of users would
not access the database simultaneously as the system as the system is directed primarily for Secure
Computing module leaders or lecturers.
2.2.5.2
SQL Server
Unlike MySQL, SQL server is not open source thus it would be highly costly to acquire, Microsoft
charge $4,999 US per processor [Microsoft, 2004]. Furthermore, as it is a Microsoft product, SQL
Server only works on Windows-based platforms whereas, MySQL supports all known platforms. Although SQL Server can deal with a lot of web traffic [Microsoft, 2004], it also consumes 250 Megabytes
of hard-drive space for a typical installation [Microsoft, 2004].
2.2.5.3
Postgresql
Much like MySQL and SQL Server, PostgreSQL is another database commonly used for web interaction. Its need for a powerful system is minimal, as stated in Gesker [2001]’s article “minimum required
memory for running PostgreSQL can be as little as 8MB”, in addition, it also can run on any platform.
However, unlike MySQL, PostgreSQL “is slower on inserts and updates” [Gesker, 2001]. Moreoever,
PostgreSQL is mainly directed at large systems and at storing a lot of data as “an empty database takes
about 1MB” [Gesker, 2001].
2.2.6 Usability
When developing a website an important factor to take into consideration is ’Usability’. High usability means that the system is easy for the user to use and easy to learn and remember. The Usability
9
guidelines ensure that the user is comfortable with using the system and can easily navigate the site.
2.2.6.1
Screen Real Estate
Screen Real Estate is the idea that web pages should be dominated by content of interest to the user
[Nielsen, 2001]. The areas of the page that haven no content are called White Spaces. A ’white space’
rule is that page content should account for at least 50% of the page but preferably 80% [Nielsen, 2001].
Nielsen [2001] informs that it is important to make use of white space as whitespaces can “guide the
eye and help users understand the grouping of information” [Nielsen, 2001].
2.2.6.2
Navigation
Web designers need to accommodate and support user-controlled navigation. Nielsen [2001] states that
it is “better to design for freedom and movement”, for example, putting a logo linked to the home page
on every page to provide context and navigation for users that have gone straight to an internal page by
a search engine.
2.2.6.3
Screen Resolution
When dealing with screen resolution, it is important to take into consideration that users have different
kinds of screen resolutions. Nielsen [2001] states that’s a web designer should never use a fixed pixel
width for any table, frame or other design element, thus designing with the resolution in mind.
2.2.6.4
Download Time
It is highly important to minimise the time taken to download a websites pages [Lynch and Horton,
2002], because users may get irritated when waiting for a page to load, this could result in a user
abandoning the page. The best way to facilitate fast page loading is to minimize the number of bytes
per page. Nielsen [2001] expresses that a web designer should try to keep pages below 100 kilobytes.
The guidelines for fast loading are defined by [Nielsen, 2001].
The top of the page should be meaningful.
Use ALT attributes on images, this will ensure that the user can see what is being loaded even
before it is loaded.
Cut down on complex tables by splitting the information into several tables.
2.2.6.5
Links
Users should not be expected to move the cursor around a website (‘minesweeping’) to determine what
is a link. Using the eyes to quickly survey the options is much faster than ‘minesweeping.’ [Nielsen,
2001]. Similarly, relying on mouse-overs to designate links can confuse newer users, and slow down all
10
users as they are uncertain about which items are links. It is therefore important to provide sufficient cues
to clearly indicate to users that an item is clickable and when an item has been clicked [Tullis, 2001].
However, the web designer must ensure that items that are not clickable do not have characteristics that
suggest that they are links.
Therefore, it is important for a web designer to be consistent with the use of underlining, bullets,
arrows, and other symbols such that they always indicate clickability or never suggest clickability. For
example, using images as both links and as decoration slows down users as it forces them to study the
image to discern its clickability [Koyani, Bailey, and Nall, 2003].
2.2.6.6
Colours
When designing a system it is important to try to use one color scheme. This is evident from Faulkner
[1998] where it is expressed that “only eight to ten different colours can be identified accurately”. The
most common colours used for text are black on white [Faulkner, 1998], in addition Faulkner [1998]
states that a developer must try to avoid using the “extremes of the color spectrum” such as red and dark
blue.
2.2.7 Accessibility
Accessibility is to make sure that all users can benefit from a website, including those that may have disabilities. Nielsen [2001] explains that accessibility “encodes meaning rather that appearance” Nielsen
[2001]. It is necessary to “provide a text equivalent for even non-text element that conveys information”
Nielsen [2001]. Thus when a site is being developed, it is important to follow the ’Accessibility Guidelines’. They allow for the visually impaired to understand the meaning of a picture. This is done by
making use of the HTML ALT attribute which provides a description for each and every image if used
correctly. Moreover, when taking colour into consideration, the website developer must make sure that
all information that is expressed with colour must also be available without colour as people that are
color blind, will find the information on the web site extremely hard to understand [Hess, 2000]. Furthermore, whilst developing a web site, the developer must ensure that a visually impaired user would
be able to resize the text and thus making it more readable.
To ensure that the accessibility guidelines would be taken into consideration during the development
of this project the A-Prompt program would be used. A-Prompt is a software tool that “examines Web
pages for barriers to accessibility, performs automatic repairs when possible, and assists the author in
manual repairs when necessary” [Centre, 2004]. This program assists web page developers with creating
a web site that is accessible to all users.
11
Chapter 3
Analysis
3.1 Analysis
The goal of the analysis was to determine the user’s needs and determine what had to be displayed on
the system and how it could best benefit its users. From the beginning of this project, meetings with
the project supervisor took place in which it was decided that two websites would be needed, an ‘internal’ and ‘external’ website. The internal site was to be a simple website which would be primarily for
the module leader to provide information to the students taking the ‘Secure Computing’ module. This
would consist of the standard features that a modules website consist of, which will be illustrated later
on in this section.
The external site proved to be a lot more complex that just creating a ‘standard website’, this was to be
developed into a user-interactive system. The external website was to be directed at external users, users
that do not take the module. One part of the external site needed to be focused on people that do not take
the module and would like to learn more about it, e.g. first/second year students and A-Level Students.
The second, secure, part of the site was to be a ’hidden’ area that could only be viewed once logged
in. This members area would be used for external tutors/lecturers (e.g. from other universities) whom
would be interested in viewing lectures notes, coursework answers, upcoming or past coursework’s,
such things that aren’t available to the average user or student.
3.1.1 The Users
The outcome of meeting with the project supervisor determined that there were three groups of people
that this project was directed at. These were classified as Students who take the ’Secure Computing
module’, Public users who do not take the Secure Computing module or aren’t part of the School of
Computing and external tutors/lecturers.
12
3.1.1.1
Students
In order to gather the requirements of the students taking the module, I performed various focus groups
where the students discussed what they required on a module website. These focus groups were recorded
and later analysed. (See focus group 1 in Appendix I) The need for a module website was clearly stated
by all the students that took part in the focus groups. The student requirements are stated below.
The students required:
a way to download lecture slides
information about the exam
a way to download coursework
a way to check for module updates or notifications
a way to gather information on Secure Computing, such as textbooks and websites
3.1.1.2
Public Users
The ‘public users’ that were addressed were mainly first and second year students. These users were
sat together in focus groups. (Focus group 2 can be seen in Appendix I) This allowed for a rigorous
assessment of the users needs, in which they conformed to tell what they believed would assists them.
These results were then reviewed and then the final requirements were gathered.
The ‘public users’ required:
information on the module
details about the site
a download area where users can download security patches
links to security related websites.
3.1.1.3
Tutors/Lecturers
As I had difficulty locating an external tutor or lecturer, their requirements were determined via some
discussions with the module leader. In addition to the ‘public users’ requirements, the ‘members’ required:
a way to register to the website
a way to login
an area in where they could download coursework answers and coursework specifications
a download area where they could download files that aren’t related to the module
13
3.1.1.4
Evaluation of module websites
Another form of gathering the requirements was the evaluation of some currently existing module websites. As the internal website was directed only at students taking the Secure Computing module, only
module websites that are within the School of Computing would be viewed. Amongst these websites
were Nick Effords - Building Distributed Systems website, Owen Johnsons - Information Systems Strategy and various other module websites such as Karim Djemames’ - Advanced Networking website.
All the websites that were examined covered all the necessary aspects that would be expected from a
module website. The layout was generally clear and straightforward. However, the navigation of the
‘Information Systems Strategy’ proved to be quite difficult to follow as the text was small and it was
laid out right at the bottom of the page. The ‘Advanced Networking website’ was the most useful site as
it provided a clear navigation bar on the left hand side of the page in addition to the website text being
clear and easy to read. The navigation of the ‘Building Distributed Systems’ web site demonstrated
to be inefficient, as when clicking on a link from the homepage, the navigation field would disappear.
However, the pages and content of the website were clear and well laid out. The chosen websites proved
to be good examples as they provided data on how to begin building the layout of the sites.
3.1.1.5
Requirement Capture for internal site
Throughout the analysis of the above websites, it was established that every module website consisted
of standard module web pages. These sites comprised a ‘Home Page’, ‘Coursework page’, ‘Exams
page’, ‘Lectures’, ‘Books’ and ‘Online Resources’. Some ideas would be taken from the above websites with regards to designing and building the layouts. In addition, the interviews and focus groups
with the students discovered that the students needed the specific pages mentioned above. Therefore,
after the analysis of the websites and further consultation with my supervisor, it was determined that the
internal website required the standard module pages, which were then classified into ‘Lectures’, ‘Online Resources’, ‘Textbooks’, ‘Coursework’ and ‘Examination’. Additionally, as the Secure Computing
module would consist of some programming, it was decided that an ‘Example Code’ page was needed.
In addition to the minimum requirements, the module leader of Secure Computing also requested
for a ‘random quote’ text to be displayed on the home page. This function would randomly select a
quote from a list of quotes residing in a database and display that random quote on the Home Page of
the website. This quote would be displayed at random every time the page gets refreshed.
3.1.1.6
Requirement Capture for external site
From these interviews and further meetings with Nick Efford, it was determined that the site would
need a standard ‘Home Page’. In addition to the Home Page it would need a page that described what
the aim of the site is which would be categorized as ‘Site Aims. The site should also include a page
that would illustrate what the secure computing module is about and what is taught in the module, later
14
known as the ‘What is Secure Computing’ page. The site must also include a ‘Download’ area, where
files would be available for download for public users. A ‘Links’ page, which would be similar to the
online resources page on the internal site, this would provide the same links as would be displayed on
the internal page and thus, ensuring that there would be ‘overlapping content’ between the two sites. As
stated in the minimum requirements, the site would need a ‘User name and Password login area’ and a
‘User Feedback’ Section.
In addition to the minimum requirements and as there was a ‘Login’ field, it would be necessary to
add a registration form so that users could request access to a ‘Members Area’ once logged in. After the
interviews and further discussion with the project supervisor it was concluded that the ‘Members Area’
should consist of a secure ‘Download’ area, in which only logged in users would be able to view and
which would consist of items such as or future lecture notes. Moreover, a coursework page was needed
which would store coursework answers or upcoming coursework briefs. Finally, I felt that the members’
area should have a ‘logout’ link and ‘Change Password’ form to assist them in solving a situation where
someone would discover their password.
15
Chapter 4
Design
4.1 Design
The prototyping methodology makes use of iterative design. This section includes the design of the
system and the process of reaching the final design, in addition to the layout of the content for each site
and database design.
4.1.1 Choice of Development Languages
As mentioned in section 2.2.3, there was a choice of four development languages, ASP, JSP, Perl and
PHP. ASP was not appropriate as it proved to be problematic when trying to run it on an Apache Server.
Speed of inserting and updating database tables was also necessary, therefore Perl was ruled out. Additionally, Perl is complex when trying to integrate web pages and databases [php.net, 2004]. Due to this
project being web based, I felt that the most appropriate language to use would be a language that was
initially designed for web development unlike JSP. Furthermore, JSP was ruled out due to its complexity
and its installation requirements. Therefore the most suitable language demonstrated to be PHP. In addition, PHP is easy to maintain due to its lack of complexities [Merriam-Powel, 2004]. Furthermore, it is
extremely easy to make PHP interact with a database [Merriam-Powel, 2004]. However, it is important
to note that I had very little experience with any of these languages; therefore, PHP had to be learnt
from scratch.
4.1.2 Choosing the Layout
This section describes the layout design process for each of the two sites. The analysis of the project
illustrated the needs of the users and what should be displayed on the sites. This section now makes use
of that information and prepares the project for the implementation stage.
16
4.1.2.1
Colors
As discussed earlier, the pages should be kept within the same color scheme; this method was followed
during the development of both of the websites. It was ensured that the colour scheme would remain
consistent throughout the whole site. A light shade of blue was specifically chosen to work with as it
represents calmness and is known to relax users [PennState, 2004].
4.1.2.2
Building the prototype for the internal site
Three prototypes were built that would act as templates for all the pages within the internal site. This
was to determine the most suitable layout for the module leader and the students taking the module. All
three prototypes can be seen in Appendix C. The first two prototypes were disregarded immediately, as
they were used to provide the layout for the third. When this prototype was shown to the module leader,
some concerns were expressed. Short interviews with students were then conducted and it was found
that they expressed the same concerns.
Figure 4.1: Third Prototype
The concerns were:
The background was too distracting.
The border around text container was too large and its location on the page in relation to the
header was disproportional.
The banner of the page was too dark and seemed unprofessional.
Both parties were however satisfied with the location of the ‘Navigation Bar’.
The concerns mentioned above were later resolved when another prototype was subsequently designed. After every change was made, both parties were asked for their opinions and their concerns
17
were taken on board during the design of every prototype. This method of iterative testing was followed
strictly throughout the development of both web sites.
There were less concerns with regards to the next construction (see figure 4.2) and the only changes
that were to be made after this was to decrease the font size in the navigation bar. Thus the final prototype
was developed (see figure 4.3) with these changes performed.
Figure 4.2: Additional Prototype
Figure 4.3: Final Skeleton. This was used as a template for all the pages within the internal website.
18
4.1.2.3
External Site Layout
Having learnt from the development of the internal site and the requirements discussed in the analysis,
it was easier to obtain a broad picture of what type of design and layout is most preferable to those who
would be using the site.
Building the template for this site began by using tables for the layout. Several problems were encountered whilst using this method. The main problem that was encountered with the use of tables was
that of accessibility. Users that use specialised tools to read through a page, such as blind users, often
find that tables make it difficult for their tools to understand the organisation of the site [Chisholm, Vanderheiden, and Jacobs, 2001]. Furthermore, tables make the size of a web page much larger and thus it
will take longer to download [Seybold, 2004]. It is also difficult to be consistent with tables because they
are inflexible. [Seybold, 2004]. Therefore the alternative was to strictly use CSS and use it for the layout.
The use of CSS allowed for the creation of a specific section on the page which would be solely
dedicated to an area on the page, such as a section on the page for the Login field or for the Navigation
bar. The page was to consist of a header and three columns. The first column would be for the Navigation
Bar which would reside on the left hand side of the page, the second column would be primarily for text
or other content that would reside in the middle of the page and the final column would be mainly for
the login form, which would change once a user logs in. All of these fields were then encapsulated into
a container. See figure 4.4 (Note that the navigation bar had not yet been implemented at this stage as I
was only dealing with the design and structure of the pages)
Figure 4.4: First External Prototype
Some of the code used to accomplish what is shown in figure 4.4 can be seen in Appendix E.
Once completed, this layout was then shown to various external users who displayed some concern
about the size of the navigation bar and the login box. In addition, there were some users that were
unsatisfied by the text size and the plain white background outside the container.
19
The template was further edited in an attempt to satisfy the users. The next template was shown to
the site users and to the module leader. Both parties were satisfied with the layout. This template was
used throughout the whole site.
For the final layout, see Appendix C.
4.1.2.4
Site Content
The page titles that were determined in the Analysis chapter were used and displayed as links in the
navigation bar. This process was also used for the external site. The content of each page will be discussed in the Implementation chapter of this report.
As download time was an issue, (see section 2.2.6.4) large images and the use of many images was
avoided. For the internal site, the only images that were used were those in the page banner and for the
external site, the navigation bar was the only item that made use of images.
4.1.3 Site Update
During the design of this system, it became clear that the updating of the site or changing the text within
a page was very tedious and not all experienced HTML coders would find this easy to do. It was therefore decided that the best way to solve this problem was to develop an ‘admin’ page which would be
dedicated purely to updating the system or viewing tables within the database.
As this page would be only dedicated to the administrators of the site, it was unnecessary to spend large
amounts of time developing a satisfactory interface. These ‘update pages’ would simply consist of a
form in which the administrators would type in the text that they would like to apply to the website,
press the submit button, and then the site would get automatically updated.
However, the ‘site update’ form would only be implemented on the external site, this was because
the internal site would be updated less frequently than the external site, due to the fact that the only major
changes made on a module website are those of adding lecture slides. This conclusion was derived from
various talks with module leaders.
4.1.4 Information Architecture
Rosenfeld and Morville [2002] define information architecture as “the combination of organisation,
labeling, and navigation schemes within an information system”. When designing a web site, it is
important to take information architecture into consideration. Information Architecture allows for a
developer to obtain a broad picture of the layout of their site. This site was developed using a ‘broad and
shallow’ approach, where breadth refers to the number of options at each level of the sites hierarchy and
depth refers to the number of levels in the hierarchy. The reason this method was chosen was because
20
there was no need for a ’narrow and deep’ approach as the users would use one navigation bar to
navigate the site and this would be consistent throughout the whole site (with regard to both the internal
and external site), such that the navigation bar would be the same on every page. In addition, there
would be no depth on the sites, as the pages would only go one level down in the hierarchy, therefore no
page would link to a page that is not accessible on the navigation bar.
Figure 4.5 illustrates the ‘broad and shallow’ information architecture and figure 4.6 illustrates the
’narrow and deep’ information architecture.
Figure 4.5: Broad and Shallow Architecture
Figure 4.6: Narrow and Deep Architecture
4.1.5 Choice of Database
As determined earlier, a database was required. Therefore, it was important to select the appropriate
database for the job. Microsoft SQL Server was immediately ruled out, as it is not open source software
and it was stipulated in the project specification that this project was to only use non-proprietary software. In addition, there was no need to purchase SQL Software at its high price, as there would be no
problem in obtaining free, open source software such as MySQL or PostgreSQL. As this project would
require a lot of user input, such as ‘user registration’, PostgreSQL, as mentioned in section 2.2.5.3,
proved to be inefficient due to its slow inserts and updates.
21
Speed was a necessity with the project and as the majority of pages in the external site would be
loaded using SQL queries, MySQL was used. This was due to the fact that it is able to quickly process
SQL queries (see section 2.2.5.1).
4.1.5.1
Database design for Internal Site
The internal site was mainly static and there was little user interaction possible. It soon became apparent
that there would not be a large need for database tables within this site.
After further discussions with Nick Efford about the content of the internal site, it was determined
that there would be a need for three tables. The first table was to be for the ‘random quotes’ (discussed
in the section 3.1.1.5) and two other tables were for the online resources page, which would also act as
the ‘overlapping content’ between the two sites. This is discussed further on in this section.
The tables had to be in Boyce-Codd Normal Form (BCNF). BCNF ensures consistency [Herndez
and Chan, 1991] and assists in avoiding the replication of the categories. A table is in BCNF when every
determinant is a primary key [Date, 2000]. This was therefore in BCNF as all fields in the table were
functionally dependant on the ID field.
Field
Type
Null
Description
ID
INT
NO
Stores the ID of each quote
quotetext
text
NO
Stores the quote
author
text
NO
Stores the author of each quote
Table 4.1: The schema of the Quotes table where ID is set to primary key and auto-increments after
every new quote is inserted. The author field is where the Author of the quote will be stored and the
quotetext field is where the actual quote will be inserted
4.1.5.2
Database design for External Site
As every page within the external site required some database interaction, there was a need for a database
table for each page. Every page would be updated from the ‘Site Update’ facility mention earlier in section 4.1.3.
The login table was used to store details about the lecturers who would sign in to the external site.
This has the field ID as the primary key, which is set to auto-increment. The usr, pwd, firstname, lastname, and email fields store the users’ user name, Password, First name, Last name and e-mail address
respectively.
22
The ‘activate’ field consisted of a long field randomly created with various characters to make it
impossible to forge. This field would then be sent to the site administrator where the administrator
would use it to make the access field equal to 1, granting the users access to the site. This table was in
BCNF as the fields were functional dependencies of the ID field.
Field
Type
Null
Description
ID
INT
NO
Stores the ID of each user
usr
varchar20
NO
Stores the users username
pwd
varchar(80)
NO
Stores the users password
firstname
varchar(20)
NO
Stores the users first name
lastname
varchar(20)
NO
Stores the users last name
email
varchar(25)
NO
Stores the users email address
activate
varchar(50)
NO
Stores the activation ID
access
INT
NO
Checks to see if the user has access rights
Table 4.2: User login Table
The feedback table stored all user feedback which would be inputted via the ‘Secure Computing’
website. The ‘SID’ field is an INT which stores student ID’s. However, not all users accessing the site
will be students. Therefore, if an SID is unavailable or a student wants to remain anonymous the table
will simply insert ‘0’ into the SID field.
The ‘name’, ‘email’, ‘subject’ and ‘feedback’ fields store the users name, their email address, the
subject of the feedback and their comments. The ‘feedback’ field was set as ‘longtext’ as it was not
necessary to limit the amount of feedback that a user should be entitled to give. All the other fields would
be set as VARCHAR. An auto-incrementing ‘ID’ field was used as the primary key that referenced the
other fields in the table. As the rest of the fields were functionally dependent on the ID field, the table is
in BCNF.
Field
Type
Null
Description
ID
INT
NO
A primary key to reference the fields
SID
INT
YES
Stores the Student ID
name
VARCHAR
NO
Stores the name of the user sending the feedback
email
VARCHAR
NO
Stores the users email address
subject
VARCHAR
NO
Stores the feedbacks subject
feedback
LONGTEXT
NO
Stores the actual feedback
Table 4.3: Feedback Table
The table ‘tbl downloads’ was created to ensure the security of the ‘members downloads’ table.
This table was also developed to store the location of each downloadable file. It was possible for a page
23
to retrieve and display the data from the tbl downloads table.
This table had four fields. ‘ID’ which was be a primary key and stored an ID of each file. The ‘description’ field stored the description of each file. The ‘filename’ field stored the location and file name
of the file. Finally, the ‘hits’ field stored the amount of times a specific file has been download. This ID
was incremented every time a file was downloaded. It also defined the rest of the fields, ensuring that
the table is in BCNF.
Field
Type
Null
Description
ID
INT
NO
Stores the ID of the file
Description
VARCHAR
NO
Stores the file description
filename
VARCHAR
NO
Stores the files directory path - Used for the URL
hits
VARCHAR
NO
Stores the amount of times the files was downloaded
Table 4.4: Download Table
The links pages make use of two tables. One table would be used to store the categories of the links
in addition to a category ID and the other would be used to store the URL of the link, its description and
a category ID.
The ER diagram for the Links and Categories relation is illustrated in figure 4.7
Figure 4.7: ER Diagram
Explanation:
A category can have many links
Each link can only have one category
‘Boyce-Codd Normal Form’ would be achieved by creating the two tables. When a user was to
select a topic from the list of categories, there would be no repetition of the categories. Figure 4.9 illustrates the links tables if they were combined, whereas figure 4.8 illustrates the tables under ‘BCNF’.
The ‘category’ table consisted of a primary key named ‘catid’ and a field for the name of the category, known as the ‘name’ field. The ‘links’ table would consist of four fields, which are illustrated
below. ‘linksid’ would be set to primary key and would increment every time a new link is inserted.
24
Figure 4.8: Normalised Table
Figure 4.9: Un-Normalised Table
This would be used to reference each of the rows in the table. The ‘href’ field will store the location
of the file on the web server to be used for downloading teaching material. The ‘cat’ field is a foreign
key that references to the ‘catid’ in the ‘category’ table. The fact that the other fields in the table were
functional dependencies of ‘catID’ meant that the table was in BCNF.
Field
Type
Null
Description
catid
INT
NO
Stores the Category ID
name
varchar
NO
Stores the category title
Table 4.5: Categories Table
The category table interacts with the links table.
4.1.5.3
Database design for ‘Site Update’ function
A table was attached to every page that made use of the ‘site update’ function. The tables were fairly
small, as they made use of two fields: ‘title’ and ‘text’. The schema of the tables is displayed below.
The ‘title’ field stored the title of the page that related to it. The ‘text’ field stored the text of that
25
Field
Type
Null
Description
linksid
INT
NO
Stores the Links ID
href
text
NO
Stores the links URL
cat
INT
NO
Stores the cat ID - Used to connect to the category table
descr
varchar
NO
Stores the links description
Table 4.6: Links Table
Field
Type
Null
Description
title
text
NO
Stores the pages title
text
longtext
NO
Stores the pages text
Table 4.7: Update Table
page. There was only one row in the table at one point in time and consequently each field was a primary
key. This ensured that the tables were in BCNF.
26
Chapter 5
Implementation
5.1 Implementation
As the analysis and design have been completed, the implementation of the system can now begin.
5.1.1 Implementation of the Database
Before any implementation could begin, it was necessary to first build the database.
The tables proposed in the Design chapter were created in the database ’SY32’. These were implemented using the command line interface, as supported by MySQL. An example of the code used is
shown below:
Creating the ‘feedback table’:
CREATE TABLE ‘feedback‘ ( ‘sid‘ int(11) NOT NULL default ’0’, ‘name‘ varchar(20)
default NULL, ‘email‘ varchar(25) default NULL, ‘subject‘ varchar(20)
default NULL, ‘feedback‘ text )
However, this method seemed tedious and very time-consuming, so a search was performed on
www.google.com to look for a graphical front-end for MySQL. This search returned a free, open-source
program called phpMyAdmin and is available from www.phpmyadmin.net. phpMyAdmin can assist in
inserting new values into tables, deleting and recreating tables, deleting fields and more, phpMyAdmin
is simply a graphical front-end to MySQL and thus it can do everything that MySQL can do. This
product can be used even once the system goes live.
Figure 5.1 displays the structure of the login table in phpMyAdmin.
27
Figure 5.1: Login table in phpMyAdmin
5.1.2 connection.php
Before the sites could be built, a means of connecting to the database had to be created. Therefore a
connection script called connection.php was written. The connection.php code can be seen
in figure 5.2.
Figure 5.2: Code for connecting to the database
This script would be included into every page that would require database usage by using PHP’s
require() function. An alternative to including connection.php in every page was to rewrite
the connection code shown above for every page. However, this seemed pointless and time-consuming
seeming that the connection.php script could simply be ‘plugged in’ by using the require()
function. In addition, having one central connection script, allows for portability. If the administrator
were to change the login and password details of the database those fields could simply be edited in one
script, the connection.php script, however, if the above code was typed into every page, the sites
administrator would have to edit every page in order to get it running on the edited database.
Therefore, every page that required database interaction, with regards to both the internal and external
sites, made use of the connection.php script.
28
5.1.3 JavaScript Validation
It was necessary to implement validation for the forms on the site. This was required to prevent users
from entering invalid characters and to ensure that all compulsory fields were completed. This validation was done using JavaScript. Although JavaScript is enabled in the majority of browsers, disabling
JavaScript in this case, would not pose any foreseeable security risk. For example, if a user were to turn
off JavaScript and then try to register to the system without inputting all the necessary fields, they would
be denied access. Some of the JavaScript code can be seen in Appendix D.
The JavaScript code was coded into one file, called function.js this code was later included into
every page that required any of those functions.
5.1.4 Site Structure
The structure of the sites that I would attempt to achieve are illustrated in figures 5.3 and in figure 5.4.
These two architectures, illustrate the ‘broad and shallow’ methods discussed in section 4.1.4. Internal
Site Structure:
Figure 5.3: Internal Site Structure
External Site Structure:
Figure 5.4: External Site Structure
29
5.1.5 Implementation of the Internal Site
Once the layout of the internal site had been determined, it was a fairly straight forward development.
It made use of the template that was created in the Design chapter. In building this site, use was made
of standard HTML code, such as tables for the ‘navigation bar’. In addition, CSS was used extensively
to ease the work of any editors who may wish to edit the layout or ‘look and feel’ of the website.
As mentioned in section 2.2.2 Server Side Includes can assist a web-developer from rewriting code,
thus, that the ‘Navigation Bar’ and the page banner would be written in two separate files, ‘nav.inc’ and
‘banner.inc’ respectively They were then included in every page on the website, a method which also
ensured consistency throughout the whole site.
The code used to include these two pages is very simple and mentioned below.
!{{#include virtual=‘‘ main includes banner.inc {{
!{{#include virtual=‘‘ main includes nav.inc {{
However, there were two pages which required more coding than the usage of standard HTML,
these two pages were to interact with the SY32 database, the ‘home page’ - needed the ‘random quotes’
function and the ‘online resources’ page.
5.1.5.1
Random Quotes
In section 3.1.1.5, it was mentioned that there would be a need for a random quote to be displayed on
the ‘Home Page’. This ‘random quote’ was to be extracted from a list of quotes stored in the database
and displayed, at random, every time a user accessed the page or refreshed the home page.
The code can been seen in Appendix D.
The quotes were provided by the module leader and, using PHPmyAdmin, all the quotes were inserted
into a table within the SY32 database.
5.1.5.2
Online Resources
The Online Resources page will consist of a drop-down menu. Within the drop down menu there will be
a list of link categories from which the user can select. Once a link is selected the page will be refreshed
and the links related to the select topic will be displayed on the page. The drop-down menu will also
remain on the page, thus, a new category can be selected even while the links of a different category are
being displayed.
The online resources page made use of the two tables discussed in the Design chapter.
As was done with every page within the system, The require(connection.php) function was
30
used to include the connection.php script. The data then needed to be selected from the two tables:
$result = mysql query("select * from category order by name asc", $connect);
The above line selects all the fields from the categories table and orders them by ascending name.
$result = mysql query("select * from links order by name asc", $connect);
This code was then inserted and it selects all the fields from the links table and orders them by ascending
name.
The retrieved ‘categories data was put into an array which was then used to created the list of topics
for the drop-down menu detailed above. Once a selection had been performed, it was necessary compare
the selected items ID to the foreign key in the links table. The below query illustrates how this can be
done:
$result = mysql query("select href, descr from links where cat = ’$catidt’",
$connect) or die(mysql error());
This retrieved data was then put into another array that was used to display to the user with the
requested links. The entire script can be seen in Appendix D.
Once the code was completed, it was then copied to the ‘Links’ page in the external site, and which
created over-lapping content between the two sites.
5.1.6 Implementation of the External Site
Much like the internal site, the layout of the external site had already been determined.
The code that was written during the design stage therefore had to be improved in order for it to be
used during the implementation stage.
The whole layout of the site, including the ‘look and feel’ of the site was created using CSS. The
text content of the pages was later inserted and as the CSS previously coded determined the font size of
the text and the font type, there was no need to hardcode a vast amount of HTML font tags.
Each page included a ‘login’ form, which would change if a user was logged in. In addition, to the login
form, every page would consist of a banner, which was a gradient image included in the CSS code, and
a navigation bar.
The site would also include two download areas, one for the public, and one for members; I would
develop two separate pages for each case. Each page would consist of a table coded in HTML with
three columns, ‘File Number’, ‘File Description’ and ‘Download’. In addition, the download table for
the member’s area would also consist of a ‘File Size’ column.
As all the pages would be .php pages, I used the require() instead of using Server Side Includes.
The reason for this was when trying to use SSI in a .php page; I found that it wasn’t possible as a page
31
that uses SSI has to have some kind of .htm extension [Apache.org, 2004]. The require() function
would perform the same job for including a page as SSI #include function.
All the downloads of the site were put into tables which were coded in HTML.
5.1.6.1
Registration
Before a user can log in, they would need to register to the SY32 system, as do most PHP scripts that
make use of forms, this feature would require two PHP scripts. One script that displays the form and
gathers the information from the users, known as the reg form.php script, and one script which will
then process the data inputted into the form known as the reg process.php script. An example of
this method is illustrated in figure 5.5:
Figure 5.5: Processing a form
The reg form.php script was mainly HTML based, as the majority of its code was building the
actual registration form. However, it made use of PHP in order to display specific error messages, such
as a username already existing in the system.
When the form data is first received by the reg process.php script, the script ensures that the
username is unique. In the event that a proposed username is not unique the script will redirect the user
back to the registration form with the URL as:
/register.php?id=5&usr=$usr’ where $usr is the username variable. The registration form
then uses this URL to display the correct error message. For example, when id = 5 it will display that
the user name already exists in the system. Possible security violations were considered, which could
occur if a user can edited the URL. However, since the user can only affect the error message displayed
on the screen, if a user were to change the URL from id = 5 to id = 1 they would just be presented
with an incorrect error method and no security breach would occur.
If the username is unique, then the reg process.php script would add the user data to the database using
the SQL shown below:
$sql = "INSERT into users VALUES(’’, ’$usr’, md5(’$pwd’), ’$first name’,
’$last name’, ’$email’,’$activate’,0)";
This query inserts the data in the variables specified. A variable in PHP is defined as ‘$variableName’ to the ‘usr’ table. The password is encrypted using PHPs md5() function. Additionally, two
extra variables are inserted into the ‘usr’ table. The $activate ID is inserted, which is used to autho32
rise users. This ID is created by generating a random id of up to 15 characters and then a unique id of
up to 114 characters, these numbers are concatenated and then the number is encrypted using md5()
which will create a 32 character identifier (a 128 bit hex number) that is extremely difficult to predict.
An example of the code is included below:
$activate = md5(uniqid(rand()));
The script sets the ‘access’ field of the current user to ‘0’. This is changed to ‘1’ once the user has
been authorised to the system. This field is used when a user tries to log into the system. Details of use
of this field are discussed in more detail below.
When a user requests authorization, an e-mail is sent to the administrator. This email includes the
users details and a URL which the administrator could access to authorize the users login.
The e-mail would make use of the variables detailed in the SQL statement, and use them to display
the user’s first name, last name, email address, and the activation ID which resides in the URL.
An example e-mail sent to the administrator can be seen in figure 5.6:
Figure 5.6: Email sent to Admin
The possibility of a security violation occurring, by a user adding themselves to the system without
authorization was considered. However, the only way a user could ‘hack’ the system and authorize
themselves was if they guessed the activation ID. As discussed above, the likelihood of a user being
able to do this is incredibly small.
Once the user has been authorised, the activate user.php script is called which authorizes
unauthorised users to the system. On calling this function the ‘activate id’ is retrieved from the URL of
the link being accessed, by using the code below:
$id = isset($ GET[’id’]) ?
$ GET[’id’] :
false;
The script then selects the users details whose ID in the URL equals to the ID in the ‘activate’ field
of the users table . The following SQL statement performs this action:
33
$sql = "SELECT usr, first name, last name, email, access FROM users
WHERE activate=’$id’";
Whether the user is authorised is checked by referencing the access field. If access is equal to 1,
then the administrator is informed that: User account has already been added to the
system. The administrator is provided with a link to close the window, which is coded in JavaScript.
The following code provides the administrator with feedback when a user has already been authorised:
echo "User account has already been added to the system";
echo "Click <a href=’javascript:window.close();’>here</a> to close this
window.";
However, if the user is unauthorised, the users access field will be changed from 0 to 1 by using the
below SQL query:
$sql = "UPDATE users SET access=1 where activate=’$id’";
The administrator will be notified that the user has successfully been added to the SY32 system. The
user will be notified by email that they are now authorised to use the system. The email will provide the
user with their user name. An example e-mail is shown in figure 5.7:
Figure 5.7: Email sent to Admin
5.1.6.2
Login
The next function that had to be developed was the login function. This function was used to differentiate between a member and a non-member. Before this could be implemented, it had to be determined
whether to use cookies or sessions. Both features are used to determine whether a user is logged in to
the system or not. The main difference between cookies and sessions is that cookies are copied over to
34
the clients’ computer, whereas sessions are stored locally on the web server. However, a problem arises
when considering using cookies. There are a vast amount of users who disable cookies on their browsers
to prevent any form of security breach, as it is not easy to monitor what cookie is being copied onto your
computer. In addition, it is possible to put malicious code into cookies, which gives the client even more
of a reason to disable cookies. In light of the above, session were chosen to work with during this project.
For the login function, two scripts needed to be created. The login form, known as login.php
and the login process, which will process the form, known as login process.php.
The first step was to build the login form, much like the registration form, this was coded in HTML.
However, login.php made use of some PHP code to display an appropriate error message if the user
made a mistake when trying to log in. The error messages can be seen in Appendix F. In addition, once
a user successfully logs in, a session is created for that user and the login form will disappear and the
user will be presented with the data shown in figure 5.8.
Figure 5.8: Logging In Box
The login process.php retrieves the data sent from the login form and then creates the temporary session, which is destroyed if the user’s log in fails.
The next step is for the script to select the users details from the users table where the users user name
is equal to the ones that were inputted into the form. The below SQL query performs this action:
$sqlusr = "SELECT usr, first name, last name, access FROM users WHERE usr=’$login’;"
The script will then move on to check if the password entered matches the user name. Which can be
seen below:
$sqlpwd = "SELECT * FROM users WHERE usr=’$login’ AND pwd=’$password’;";
The script now has to check if the user is authorised to access the system. This is done by checking if the
users ‘access’ field is equal to 1, if it is, then the user is authorised and is redirected to the sites home page
with a logged in session and an added ‘members area’ on the navigation bar However, if the user isn’t authorised, then the session will be destroyed using PHP’s session destroy() function and the script
will redirect the user back to the home page with the URL as /external/index.php?id=3. The
login.php script will use this to display a message notifying the user that they haven’t yet be authorised to the system. In addition, if the user has inputted an incorrect username or password, the session
will get destroyed and an ID will be sent in the URL which will tell the login.php script to display
the appropriate error message.
Once logged in, the user can also log out of the system, by clicking on the logout link which calls
35
the logout process.php script. This script will simply destroy the session and redirect the user
back to the home page.
5.1.6.3
User Feedback
The next script that was implemented was the feedback script. The feedback function would simply
record the data inputted from the site and store it in a database. The feedback can be of any topic,
e.g. feedback on the site or feedback on the module. Once again, two scripts were used for the
building of this page. This first script, feedback.php was the feedback form, the second script,
feedback process.php was the script that would process the form and enter the data into the
database.
The feedback process.php script would receive the data sent to it from the feedback.php
script and then using the query below it would enter the data into the database.
$sqlquery = "INSERT INTO feedback VALUES(‘‘$sid’,‘$firstname’,‘$email’,‘$subject
The script will also record a students ID if such an ID is present.
Once the script has successfully been processed, it will return the user with a message stating that the
user’s feedback has successfully been recorded.
5.1.6.4
Members Area
The members area is the area that will consist of all the private things that a ‘normal’ user cant do. This
section will be available in the navigation bar once a user logs in. Whether to display the ‘members area’
or not, is determined by using an ‘IF’ statement. The ‘IF’ statement is present on every page within the
site, and it states: ‘IF the user session exists, then display the ‘members area’ in the navigation’ bar,
if a session doesn’t exist, then display the normal page’. This method is used to display any kind of
information that should only be available once a user is logged in. This code is shown in Appendix D.
The navigation bar with the ‘members area’, is shown in figure 5.9.
The member’s area consists of a ‘Downloads’ page, a ‘Coursework’ page and a ‘Change Password
page. In addition, a ‘logout’ page is present for when a user wishes to logout.
5.1.6.5
Change password
A change password function is a necessity with regards to security. If someone were to discover a user’s
password, the user must have the means to change their password, thus, the ‘change password’ script
was developed.
The form part of this script would require for the password to be entered twice, to ensure that the user
hadn’t made a mistake whilst entering the password. This script process would begin by checking if
36
Figure 5.9: Members Navigation Bar
a session is alive, it would then check if the two passwords that were entered match. If the passwords
match, the script will then check to make sure that those are not blank, if this is true, then further validation will check whether the passwords length is longer than five characters as a password with less than
five characters is classified as a poor password. Once all these checks return TRUE, then script will use
the below query to update the database with the user’s new password.
$sql = "UPDATE users SET pwd = ’$pwd’ WHERE usr = ’$login session’";
However, if any of these checks return FALSE, then the script will redirect the user back to the
‘change password’ page with the URL as change password.php?id=7 where ID will determine
what error message to display. For example, if ID in the URL would equal to 6 then the ‘change
password’ page would display “You cannot have a blank password”.
5.1.6.6
Member Downloads
During the development of the members download page, a problem was encountered that was quite
serious with regards to security. The problem was that when downloading a file over the Internet, the
file download link is simply a link to a different location. Therefore, if a user was to obtain that link to
the secure file, by viewing the links properties, they could easily view the location of the file and then
paste that link into any web browser, which would automatically download the requested file whether
the user was logged in or not. In addition, this link can easily be passed onto a ‘non-member’ and thus
the non-member can use the link to download secure files. Moreover, there are programs available on
the Internet, such as ‘Softbyte Labs: BlackWidow’ which can be used to download the whole content of
a website. A PHP script was therefore developed in an attempt to solve this problem. This script would
ensure that only logged in members could download the secure files.
37
As mentioned in section 4.1.5.2, it can be seen that the tbl downloads table stored all the details
of a file, including its location on the web server. This data was retrieved by the ‘downloads’ page in the
members area and displayed on the page in a table coded in HTML and PHP. The table would display
the file description and the file size which will allow for the user to know how big the file that they
are downloading is. This facility will assist users who are connecting to the site via a slow internet
connection. The table can be seen in figure 5.10
Figure 5.10: Member Downloads Table
The code used to build the table shown in figure 5.10 can be seen in Appendix D.
As mentioned in section 4.1.5.2 of this report, it can be seen that the ‘tbl downloads’ table
consisted of a file ID. This ID was later used to secure the download links.
By using the PHP code that was used to develop the downloads table which made use of the file ID, it was
possible, for example to change the download URL from /files/3.doc to /pages/members/get downloads.php
and thus hiding the actual location of the file.
However, even though this was accomplished, a non-member could still use the converted URL to
download a secure file. Therefore, the get downloads.php script was developed. This script does
a few things. The first thing that this script would do is retrieve the ID from the URL.
For example, if a user was to click on a download link, the browser would display a URL that would
look something like /pages/members/get downloads.php?id=3. The ID would later be used
as a reference to the location of a file. These details would be stored in the database and would be used
to correspond to a file stored on the web server.
The next step taken is to ensure that the user is logged in, if the user is logged in, the script can
proceed to the next step.
The next step would tell the browser the location of the requested file in order to proceed with the
download. This is done by checking where the retrieved ID from the URL is equal to a file ID stored in
the database.
In addition, the script would increment the amount of hits every time a file is downloaded. This can be
extremely beneficial for the site’s administrator as the administrator would able to get an idea of what
the most popular files are and thus remove the least popular file, consequently saving on storage space.
The below SQL query illustrates how the script selects the correct file:
38
$sql = "SELECT filename, hits FROM tbl downloads WHERE id=’$id’";
The file is then outputted to the browsers and is downloaded by the user.
However, if a user is not logged in and they tried to download a restricted file, they would be returned
with an error message stating that they are “unauthorised to access this page”.
5.1.7 Site Update
As mentioned previously it was necessary to develop a function that would allow for the administrator
to update the web site without doing any major editing of the pages. The method that was taken when
implementing this script was to ensure that every page that made use of text would connect to a database
to retrieve the text related to its page.
This was created using the same method discussed previously, by having a script with a form in it and
another script which will process the form. When the administrator loads up the form related to a specific page within the site, it will show the text data that is currently being displayed on that page in
the forms field. Furthermore, the form will also have another field which will display the current title.
A screen shot of this method can be seen in Appendix G. Once the administrator makes the necessary
changes to the text, the submit button is clicked and the process script will then run the below query to
update the database.
Update database SQL query:
$sql = "UPDATE update index SET title = ’$title’, text = ’$text’";
This same method was used for all the pages that made use of text for the content of the page.
Furthermore, the administrator will be able to add quotes and their authors to the ‘random quote’ function on the internal site via the same kind of method. However, instead of using the UPDATE function
shown above, this script will make use of an INSERT function, shown below:
$sql = "INSERT INTO quote VALUES (’’,’$quotetext’,’$author’)";
5.1.7.1
File Upload
In addition to being able to update the text on a page, administrators will also be able to update the
download tables by using a ‘file upload’ function.
When loading the file upload page, the administrator will be presented with the form shown in figure
5.11.
Figure 5.11: Upload Form
The administrators can then browse for a file, and enter the file’s description. Once the form is
39
submitted, the uploaded file will get copied to the file storage directory and the table in the database will
have a new row added to it with the new file name, its description, the location of the file on the server
and how many times the file has been downloaded (which would be 0).
If an error is encountered during the submission of the file, for example, if the file was in use at time of
upload, then an error message will be displayed on the administrator’s browser notifying the administrator that the upload has failed. A link will also be provided that will redirect them back to the upload
form.
The ‘downloads’ page script will then extract this newly added data from the database and display it in
the downloads table within the ‘downloads’ page.
The code for both the upload script and the downloads table can be seen in Appendix D.
5.1.8 Viewing/Editing tables
I found that for an administrator to have to use MySQL command line every time a table wanted to be
viewed or edited was very tedious. Furthermore, even though PHPmyAdmin is an excellent program
for creating and editing tables, it can be fairly tiresome having to load it up just for a simple viewing of
a table. Therefore, an HTML based web page was created which would allow for the administrator to
click on a link in order to view or edit a table related to a specific page. This link would simply link to
the table in PHPmyAdmin, and load it up in a new browser window. The list can be seen in figure 5.12
Figure 5.12: View/Edit tables list
However, as the feedback wouldn’t require any editing, due to the fact that user feedback should be
purely for viewing and analysis purposes, a script was created that would display the table in a table in
a browser window which cannot be edited.
The ‘feedback’ table can be seen in figure 5.13
5.1.9 Security
Due to this project being developed for a ‘Secure Computing’ module, it was imperative that the website
would be secure. The security was designed with the ‘user login’ and SQL Injections in mind.
40
Figure 5.13: Feedback Table
The first aspect that needed to be checked was whether a user is logged in or not. This was done by using
the isset($ SESSION[’firstname session’]). When placing the isset function next to
an IF statement, for example IF(isset($ SESSION[’firstname session’])) it is possible
to determine whether a user session for a specific user is set (or exists). Consequently, this will check
whether the user is logged in or not, if the user is not logged in, they will be presented with a message
saying “ You are unauthorised to access this page”.
The code can be seen below:
if(isset($ SESSION[’firstname session’]))
MEMBER CONTENT HERE
else
ECHO "You are unauthorised to access this page";
The next security issue that was considered was SQL injections. SQL Injections is a way that a malicious user can input their own code, normally an SQL query, into a form and thus perform unauthorised
actions. The way to solve this problem is to use PHP‘s addslashes() or mysql real escape string()
function, these two functions put a slash before any illegal characters such as such as quotation marks
which could be used in a malicious SQL query. The slashes are used to escape any malicious code from
being used or executed.
The mysql real escape string() function was used for all the forms within the site, because
the mysql real escape string() is specific to the database that was being used. When it was
necessary to display the information that had been inputted on one of the webpages, for example when
displaying the user feedback tables, a function was used called stripslashes() which would remove all the slashes added by mysql real escape string()
41
Chapter 6
Testing
6.1 Testing and Evaluation
6.1.1 Testing
In order to determine whether the system is fully functional, it is necessary to perform specific tests on
the system. The testing process was undertaken during and after the development of the product. In
addition, after every script was developed it was tested to ensure that it works. There are two types of
testing methods that need to be taken in order to achieve a successful system, these methods are known
as: Unit Testing and System Testing
6.1.1.1
Unit Testing
Elena Garc, Miguel, Cuevas, and D [2002] states that Unit testing is about “test a little, code a little” and
every time the code changes, run the same tests. This method was taken throughout the development of
every script and allowed for me to determine where the errors in the script were in addition to checking
if it functioned accordingly.
6.1.1.2
System Testing
On completion of the product, it was necessary to test the product as a whole. This method is known
as system testing. Its job is to point out errors that may have been missed during the implementation
and after, the problems that are found are then dealt with at this stage [Petschenik, 1985]. This process
was used to test the system as a whole unlike the unit testing method that tests ‘units’ after every stage
of their development. System Testing was performed after the completion of both products, both on the
internal and external sites.
42
6.1.1.3
Problems
Problems encountered will now be discussed.
During the design stage, I came across a factor that was uneasily solved. The problem was developing
the layout of the sites using tables. However, the unit testing method proved to me that this technique
wasn’t feasible as tables prevented me from getting the exact layout that I desired.
One of the first problems that were encountered during the testing process, was that when inserting a
student ID into the feedback form, the database hasn’t got the ability to store a ‘0’ as a first digit, so
for example, if a student were to enter ‘013-256-786’ into the feedback form, the database would only
display ‘13-256-786’ this problem is currently still outstanding and I am yet to figure out to resolve it.
A further error that I encounter was that if a user tried to register another username whilst logged into
to the system, the script would produce many PHP based errors. After extensive editing, I was unable
to solve this problem. It was assumed however that a user should not be allowed to register another user
name whilst logged in. I therefore removed the registration link from the Navigation Bar for when a
user was logged in.
A major problem that I had extreme difficulty solving was that of the securing the member downloads
table. After some thinking the successful method that I achieved was implemented.
6.1.1.4
Browser Compatibility
It was necessary to ensure that the system would be cross browser compatible. With reference to figure
2.1, I allowed for myself to concentrate on the most commonly used web browsers, these were classified
as the most up-to-date browsers. The way this was tested was by making use of a website known as
browsercam.com (www.browsercam.com). Once I had determined the layout, I was able to upload my
site to the Internet, paste in the URL of my website to browsercam.com and then browsercam.com
would return all the web browsers that my site was compatible with. As not all websites can be relied on
and as browsercam.com could have encountered some errors that I was unaware of, I performed some
additional tests on the most common web browsers shown in figure 2.1. Both sites successfully passed
these tests. However, when viewing the site in Mozilla, I found that it didn’t look as good as it did when
viewing it in Internet Explorer.
6.1.1.5
Resolution
Having tested what browsers the site worked on, I could now determine what resolutions the site would
work on. After the test, I found that the sites worked on all resolutions, however, with regards to the
external site, on resolutions below 800x600 a scroll bar would appear as the page wouldn’t fit directly
on anything below 800x600. However, the site still functioned correctly and was clearly viewable.
43
6.1.1.6
Security
Security testing was essential. A worst-case scenario would be if the Secure Computing website got
hacked, I therefore ensured to the best of my abilities that the security of the external website could not
be compromised. The SoC provided the security for the internal site by using a. htaccess file. I tried
rigorously to forge a user name and password by using various combinations of random user names and
password and trying to log in with them. I also tested SQL Injections on all the forms in the website.
One of the SQL Injections I performed on the feedback form was:
Feedback Form Input:
inject’; $sql = "select * from users"; $result = mysql query($sql); echo
$result;
This injection proved unsuccessful, a slash was added before every malicious character therefore no
malicious action could be performed and the database remained secure. The database displayed:
inject ’;
$sql =
"select * from users "; $result = mysql query($sql);
echo $result;
However, when the administrator would view the feedback table from the administrators view, all
the extra added slashes were removed due to the usage of the stripslashes() function.
In addition, once the web browser is shut down, the user session is destroyed and the user is automatically logged out.
6.1.1.7
Performance
In addition to the above testing I found it was necessary for the system to undergo some performance
tests. Although the impact of broadband in this country and many other countries has been immense, it
is still true to say that the majority of internet users are still using dial-up connections and 56K modems.
It was therefore important to ensure that the system was able to accommodate for users on both fast
and slow connections. As mentioned in section 2.2.6.4, the number of images used in the systems was
minimal by design ensuring minimal load time, even on the slowest of connections. After testing on a
56K modem, I found that the sites would be fully downloaded within an average of 4 seconds.
6.1.1.8
Administration section
All the functionality deployed for the Admin area, such as updating the site and viewing/editing tables
worked and functioned correctly. However, if the administrator was to type a false filename when
uploading a file to the database via the upload form, a file with this filename would get created and
uploaded to the download table within the site. This problem has yet to be rectified. However, not much
44
time was spent on the problem, as I assumed that any user using this function would only use the browse
button, as this is most common amongst users.
6.2 Evaluation
6.2.1 Evaluation
This chapter evaluates how well the project was completed and how successful the solution was. It
begins by discussing the minimum requirements and determining how they were achieved. In addition,
it illustrates how the minimum requirements were exceeded. In order to perform an effective evaluation,
I set myself evaluation criteria.
6.2.1.1
Evaluation Criteria
The following criteria were used to determine whether I met the objectives that I set myself in the
introduction chapter and to see whether I developed a solution to the problem by following the minimum
requirements.
Meets the minimum requirements
Exceeding the minimum requirements
Selection of a good methodology
Satisfactory Implementation
Good Design and User Satisfaction
Solution of the problem
6.2.1.2
Evaluation of Minimum Requirements
In order to determine how successful the project was, it was essential to meet the minimum requirements. If the minimum requirements were not met, this project would have been classified a failure.
The minimum requirements will now be evaluated.
Requirement 1: Internal website accessible only to students
This requirement was accomplished by creating the SY32: Secure Computing student website. By using
the. htaccess file provided by the School of Computing I was able to ensure that only students would
log in. In addition, the module leader expressed satisfaction.
Requirement 2: External website for external users (non-students) with overlapping content
This requirement was accomplished using various technologies to design and develop the website, in
45
addition, it provided the necessary functions discussed in the meetings with the project supervisor. Furthermore, it satisfied the requests of the interviewees mentioned in section 3.1.1.6 .
Providing an identical online resources page for both the Internal and External site by using one central
table for both sites satisfied the overlapping content part of this minimum requirement.
Requirement 3: Cross-browser compatibility
As section 6.1.1.4 determined, it is possible to see that both sites were successfully cross-browser compatible regarding the most commonly used web browsers.
Requirement 4: Security, with user name and password log in function
The Security part of this requirement had a few aspects mentioned earlier, such as PHP’s addslashes()
and verifying that a user is logged in. The login feature was successfully implemented using various
kinds of method and this function differentiated between both members and non-members.
Requirement 5: User feedback
The final function that was required was the user feedback method. This feature was accessible to all
users and was implemented using standard HTML and PHP. This section of the project allowed for both
members and non-members to leave any form of feedback regarding any topic.
As is clearly visible from this evaluation, the minimum requirements where successfully achieved.
Moreover, both systems were successfully created and thus this project met its aim. Furthermore, Nick
Efford stated that “as a user of the system, I am very satisfied”. However, I felt that there was a need for
additional features to be added to the system. These features will now be discussed.
6.2.1.3
Exceeding the minimum requirements
As mentioned above, I found it necessary to go beyond the projects minimum requirements. Therefore,
various functions were developed.
Additional 1: Quotes
This feature was displayed on the home page of the internal site and was purely for educational purposes. It would display a random quote related to secure computing every time the home page is loaded
or refreshed.
Additional 2: Registration Form
This feature allowed for users to register to the system, which in turn would compliment the login feature, as a user wouldn’t be able to log in without a user name and password.
Additional 3: Activating users
46
As not all users are allowed to directly add themselves to the system, the activate user script was developed which allowed for the administrator to activate selected users and allow them to access the
members area.
Additional 4: Email Response activating users
Due to having built the registration form, I found that it was essential to notify the administrator when a
user registers and notify the user that they have been authorised.
Additional 5: Member Downloads
This feature was developed in order to secure the ‘member downloads’ page and proved to be successful
and efficient. This was one of the harder problems that I encountered. I had to be certain that a nonmember would not be able to download any files that they had no access to. Furthermore, once a file is
uploaded, this script would immediately retrieve the uploaded data and add it to the page.
Additional 6: Change Password
As this system made use of users, the user must have the ability to change their password. The feature
would also assist the security of the system such that if a user’s password was compromised, it could
simply be changed within a matter of seconds.
Additional 7: Logout
A further function that was developed was the logout function. This allows for users to log out once
they have finished using the system.
Additional 8: Page Update
The page update feature, as all the other admin pages, would sit on the intranet and would only be
accessible to those who have the rights to update the page. This featured was developed solely for the
administrators to easily update the web pages without having to do any major editing of HTML.
Additional 9: File Upload
As there was a download area, it was determined that there would be a need for a File Upload function,
which like mentioned above, would also assist the administrators for when there was a need to upload a
page.
Additional 8: Viewing Tables
Due to the confusion generated by the many tables that are used within these websites, a convenient way
to view the data was implemented by developing a web page that would link to all the tables in addition
to developing a script for viewing the feedback table.
All the above requirements were successfully deployed. However, there were more features that
47
were wished to be implemented, such as a search engine and online news feed, although, due to the time
constraints this didn’t prove to be feasible.
6.2.1.4
Selection of a good methodology
The chosen methodology proved to be the correct methodology to use. It proved to assist during the
design stage of the project, where several prototypes were developed and evaluated. When a complaint
was made regarding one of the designs, the prototyping methodology allowed for the stepping back and
re-developing of the design. Had this methodology not been chosen, the necessary iterative stages could
not have been accomplished.
6.2.1.5
Satisfactory Implementation
Throughout the whole implementation, I ensured that my code would be fully commented and written
with the correct indentation. The purpose of pursuing such a strict method of commenting all my code
was for future site editors who may need to make use of the code or enhance it. By commenting and
indenting all my code, programmers will be comfortable when reading it and be able to sense of it.
Furthermore, even a non-experienced programmer would be able to get a picture of what is occurring in
the script.
6.2.1.6
Good Design and User Satisfaction
As the users are the key players in this product, it was exceptionally important to make certain that they
were comfortable using the systems and that the users found the systems to be satisfactory. Sending a
questionnaire to various users and then evaluating their feedback determined the how good the design
was and the user satisfaction for both sites. The questionnaire was taken from [Chin and Norman, 1988]
The sections of the questionnaire were put into categories:
OVERALL REACTION TO THE SOFTWARE
SCREEN
TERMINOLOGY AND SYSTEM INFORMATION
LEARNING THE SYSTEM
SYSTEM CAPABILITIES
For the external site:
48
Avg
Avg Min
Avg Max
OVERALL REACTION TO THE SOFTWARE
7
5
9
SCREEN
8
6
9
TERMINOLOGY AND SYSTEM INFORMATION
8
6
9
LEARNING THE SYSTEM
8
5
9
SYSTEM CAPABILITIES
8
6
9
The results of the questionnaire indicated that the majority of users were satisfied with the system.
However, a minority found the design of the site unsatisfactory, as noted by one user, “font size could
possibly be larger”, whereas some users evaluated the site as “Visually pleasant”. Since the evaluation
was conducted at a late stage of the project, regrettably, time constraints prevented further improvement
of the design. Nevertheless, some positive comments were also received, most users portrayed the fact
that the site was “easily navigable” and that they had a “clear idea of what you have to do”.
A major problem that was expressed by the module leader was “Login error messages are insecure; you
should not indicate which of username or password was incorrect!”. After realising that this problem
was critical, the script was reconfigured and the problem was eliminated. Additionally to the questionnaires, I performed some one-on-one interviews with fellow students and external users. The majority
of users were satisfied by the end product and I received comments such as “I really like the menu”
However, some negative comments were received such as “the design is a bit plain” these problems
were later rectified, as they only required a minimal amount of editing.
For the internal site:
Avg
Avg Min
Avg Max
OVERALL REACTION TO THE SOFTWARE
7
5
9
SCREEN
8
5
9
TERMINOLOGY AND SYSTEM INFORMATION
8
6
9
LEARNING THE SYSTEM
8
7
9
SYSTEM CAPABILITIES
8
7
9
In addition to the module leader, this questionnaire was only sent to students taking the Secure
Computing module. The results of the questionnaire were more satisfactory than the external site. Only
one negative comment was received concerning the ‘Random Quote’ function. One user expressed that
“the quote text is too small”. However, most users were satisfied with the as comments such as “ nice
colour scheme” and “very easy to navigate” were received.
6.2.1.7
Solution to the problem
As mentioned in section 1.1.2, the project aim was “To produce a secure website for the Secure Computing module”. The above evaluation proves that this was successfully achieved. The functionality
that was deployed on both sites worked successfully and therefore the project aim was achieved. On the
49
basis of these grounds, I can securely say that the developed product solved the initial problem.
6.2.2 Further Enhancements
Search Engine - A search engine could assist a user when they are looking for a file amongst many
other files contained within the site.
News Feed - A live news feed is a function that retrieves the latest news updates from a central
database. The function will display the retrieved content on the web site. Although this feature
was spoken about with the module leader, time constraints restricted this function from being
considered.
Levels of access - Currently, all the members logging on to the external site have the same access
levels. Further implementation could allow for ‘special’ members to view areas that ‘normal’
members cannot.
50
Bibliography
Apache.org.
Apache
tutorial:
Introduction
http://httpd.apache.org/docs/howto/ssi.html, March 2004.
to
server
side
includes.
D.E. Avison and G. Fitzgerald. Information systems development : methodologies, techniques and tools.
McGraw-Hill, 3rd edition, 2002.
D. Axmark and M. Widenius. Mysql introduction. Linux J., 1999(67es):5, 1999. ISSN 1075-3583.
C. M. Boroni, F. W. Goosey, M. T. Grinder, and R. J. Ross. A paradigm shift! the internet, the web,
browsers, java and the future of computer science education. In Proceedings of the twenty-ninth
SIGCSE technical symposium on Computer science education, pages 145–152. ACM Press, 1998.
ISBN 0-89791-994-7.
Adaptive Technology Resource Centre. A-prompt project. http://aprompt.snow.utoronto.ca/, March
2004.
V.A. Chin, J.P.and Diehl and K.L. Norman. Development of an instrument measuring user satisfaction
of the human-computer interface. ACM CHI’88 Proceedings, pages 213–218, 1988.
Wendy Chisholm, Gregg Vanderheiden, and Ian Jacobs. Web content accessibility guidelines 1.0. interactions, 8(4):35–54, 2001. ISSN 1072-5520.
W. Sam Chung and Don McLane. Developing and enhancing a client/server programming for internet
applications course. J. Comput. Small Coll., 18(2):79–91, 2002.
C.J. Date. An Introduction to Database Systems. Addison-Wesley, 7th edition, 2000.
Barriocanal Elena Garc, Sicilia Urb Miguel, Ignacio Aedo Cuevas, and Paloma D. An experience in
integrating automated unit testing practices in an introductory programming course. SIGCSE Bull.,
34(4):125–128, 2002. ISSN 0097-8418.
Christine Faulkner. The Essence of Human-Computer Interaction. Prentice Hall, 1998.
Kenneth W. Fiduk, Sally Kleinfeldt, Marta Kosarchyn, and Eileen B. Perez. Design methodology management a cad framework initiative perspective. In Conference proceedings on 27th ACM/IEEE design automation conference, pages 278–283. ACM Press, 1990. ISBN 0-89791-363-9.
51
Dennis Gesker. Alternatives for dynamic web development projects. Linux J., 2001(83es):6, 2001.
ISSN 1075-3583.
Luis Gravano, Panagiotis G. Ipeirotis, and Mehran Sahami. Qprober: A system for automatic classification of hidden-web databases. ACM Trans. Inf. Syst., 21(1):1–41, 2003. ISSN 1046-8188.
Neil Gray. Web Server Programming. Wiley, 2001.
Doctor J. Herndez and Edward P. F. Chan. Constant-time-maintainable bcnf database schemes. ACM
Trans. Database Syst., 16(4):571–599, 1991. ISSN 0362-5915.
R. Hess. Can color-blind people see your site. 2000.
Sanders Jr. Kaufman. Mysql or sql server: Look beyond politics and hype when deciding which to use.
2003.
Craig Knudsen. Php version 4. Linux J., 1999(67es):8, 1999. ISSN 1075-3583.
Sanjay J Koyani, Robert W Bailey, and Janice R Nall. Research-Based Web Design and Usability
Guidelines. U.S Department of Health and Human Services, 2003.
K.E. Lantz. The Prototyping Methodology. Reston Pub Co, 1987.
K. W. Lie and J. Saarela. Multipurpose web publishing using html, xml, and css. Commun. ACM, 42
(10):95–101, 1999. ISSN 0001-0782.
Doug Lowe. Client/Server Computing for Dummies. IDG Books worldwide, 1995.
P.J. Lynch and S. Horton. Web Style Guide: Basic Design Principles for Creating Web Sites, Second
Edition. Yale University Press, 2002.
R .E. A. Mason and T. T. Carey. Prototyping interactive information systems. Commun. ACM, 26(5):
347–354, 1983.
Merriam-Powel. Intro to jsp. http://denali.cse.nau.edu/SERF/jsp.php?action=tech, March 2004.
Microsoft. Microsoft sql server. http://www.microsoft.com/sql/evaluation/sysreqs/2000/, March 2004.
Audris Mockus, Roy T. Fielding, and James Herbsleb. A case study of open source software development: the apache server. In Proceedings of the 22nd international conference on Software engineering, pages 263–272. ACM Press, 2000. ISBN 1-58113-206-9.
Jakob Nielsen. Designing Web Usability. New Riders, 2001.
PennState. Architecture and design. http://ict.cas.psu.edu/Training/instrmats/AandD/Tools.html, Aril
2004.
52
perl.org. About perl. http://www.perl.org/about.html, March 2004.
N. H. Petschenik. Building awareness of system testing issues. In Proceedings of the 8th international
conference on Software engineering, pages 182–188. IEEE Computer Society Press, 1985. ISBN
0-8186-0620-7.
php.net. Php: Php and other languages - manual. http://uk.php.net/manual/en/faq.languages.php, March
2004.
J. Purtilo, A. Larson, and J. Clark. A methodology for prototyping-in-the-large. In Proceedings of the
13th international conference on Software engineering, pages 2–12. IEEE Computer Society Press,
1991. ISBN 0-89791-391-4.
L. B. S. Raccoon. Fifty years of progress in software engineering. SIGSOFT Softw. Eng. Notes, 22(1):
88–104, 1997. ISSN 0163-5948.
Allen Riddell. Core php programming: Using php to build dynamic web sites. Linux J., 2000(69es):31,
2000. ISSN 1075-3583.
Louis Rosenfeld and Peter Morville. Information Architecture for the World Wide Web. O’Reilly, 2002.
Seminars Seybold. The problem with using tables. http://www.hotdesign.com/seybold, March 2004.
N. Scott Strong. Identifying a complete object oriented life cycle for large systems development. In
Proceedings of the conference on TRI-Ada ’92, pages 166–175. ACM Press, 1992. ISBN 0-89791529-1.
T.S Tullis. Web usability lessons learned. Fidelity Center for Applied Technology, 2001.
University of Utah. Learning perl. http://medstat.med.utah.edu/medstat ops/node182.html, March 2004.
w3schools.com. Browser statistics. http://www.w3schools.com/browsers/, March 2004.
53
Chapter 7
Appendix A
This project is one of the hardest tasks and by far the biggest tasks that I have ever attempted to accomplish.
At the start of the project, I had difficulty in planning and keeping to the time schedule I planned. This
was mainly due to the misconception throughout that there was more time left than there actually was.
I later learned how wrong I was. Luckily for me, I grasped my error early in the project and thus it was
simply to rectify.
If there was only one thing that I learnt from this project, I would have to say that it was ‘timemanagement. If I had to do the project again, I would certainly manage my time in a more efficient
way, and I would make a strict attempt in sticking to that schedule.
One of the things that I feel brought me down was underestimating how much work the final write-up
would require. Furthermore, the background research section consumed more time than intended. The
background research chapter is critical. However, I found that it is important not to spent too much time
on it.
Without the used methodology, there could have been no way that this project would have been a success. When developing any form of system, you MUST have a methodology. At some points during
this project, I may have strayed from the methodology and this is where I encountered problems. For
the future, I know that I should strictly follow the selected methodology.
There are numerous lessons that I have achieved throughout the duration of this project. Not only have
I learnt the importance of time-management skills, but I have also learnt what needs to be undertaken
to develop such a large project. Furthermore, I have come out with practical skills, such as learning
a scripting language in limited time and the procedure required when designing and developing a web
based systems which are incredibly useful in the work place.
54
Having said the above, I feel that there was an area of this project that let me down. This was the
final write-up. I feel that my practical skills are a lot better than my writing skills.
55
Chapter 8
Appendix B
Gantts Chart in main report
56
Chapter 9
Appendix C
The below screen shots display the three skeletons built for the internal site:
57
Figure 9.1: First Skeleton
58
Figure 9.2: Second Skeleton
59
Figure 9.3: Third Skeleton
60
Figure 9.4: Additional Skeleton
61
Figure 9.5: Final Skeleton
62
Figure 9.6: Final External Layout
63
Chapter 10
Appendix D
Figure 10.1: Snippet of JavaScript Code
The below code displays the IF statement used to secure the members area:
if(isset($ SESSION[’firstname session’]))
MEMBER CONTENT HERE
64
Figure 10.2: Random Quotes Code
Figure 10.3: First part of Online Resources code
else
ECHO "You are unauthorised to access this page";
Need to put all scripts here.
65
Figure 10.4: Second part of Online Resources code
Figure 10.5: Member Downloads Table
66
Figure 10.6: Upload Process script
67
Chapter 11
Appendix E
68
Figure 11.1: Snippet of CSS Code
69
Chapter 12
Appendix F
Login error messages before evaluation:
//retrieves the ID from the URL $id = isset($ GET[’id’]) ? $ GET[’id’] : false;
$status = ””;
if ($id == 1)
$status = ”User does not exist. Please try again.”;
else if ($id == 2)
$status = ”Password for user not recognized. Please try again.”;
else if ($id == 3)
$status = ”Your account is awaiting authorization or you have not been authorised to access this webpage.”;
Login error messages after evaluation:
//retrieves the ID from the URL $id = isset($ GET[’id’]) ? $ GET[’id’] : false;
$status = ””;
if ($id == 1)
$status = ”Username or password is incorrect. Please try again.”;
70
else if ($id == 3)
$status = ”Your account is awaiting authorization or you have not been authorised to access this webpage.”;
71
Chapter 13
Appendix G
Updating the External site:
Figure 13.1: Updating the External site
72
Chapter 14
Appendix H
This appendix displays the questionnaire used for the project evaluation:
73
Figure 14.1: Questionnaire used for evaluating both websites
74
Chapter 15
Appendix I
Figure 15.1: Focus Group 1
75
Figure 15.2: Focus Group 2
76