A web portal with

(1)

IN

DEGREE PROJECT COMPUTER ENGINEERING, FIRST CYCLE, 15 CREDITS

STOCKHOLM SWEDEN 2017,

A web portal with

usersubmitted content

Creating a web portal and minimizing its need for administrative work

DANIEL WINGE

CHRISTER WINGE

(2)

(3)

Abstract

A web portal that publicly displays user-submitted content requires administration in order to ensure undesired content, that is potentially malicious, is excluded. Other administrative aspects that come with a web portal with user-submitted content include user-support and service maintenance. This project was formed in part to develop a new version of an existing web portal for advertising degree projects. The goal of the project is to develop an improved version of the old web portal and ensure that the new version requires as little manual administration work as possible. As how to minimize administration for this type of service was deemed unknown, this thesis takes an inductive approach to exploring how to minimize administration for a web portal with user-submitted content.

This thesis results in the presentation of a web portal with new functionality and modified in aspects that the product owner wanted improved. The visual layout is presented along with information on what parts were reused from the old version of the web portal. Design choices that were made with a focus on minimizing administration and design choices in general that were deemed important are presented and mo- tivated. Finally, the thesis concludes that possible areas where administrative work could be reduced depends heavily on the requirements set on the web portal and that the methods used in this thesis were successful in identifying administrative work aspects that can be reduced or eliminated on the web portal developed in this project. It is also concluded that sufficiently advanced automated systems could be useful in reducing the administrative work needed by any type of web portal with user-submitted content.

Keywords

Web portal, Software, Administration, Minimal, Minimize, Degree project

(4)

Abstract

En webbportal som publikt visar användarskapat innehåll kräver administration för att försäkra att oönskat innehåll, som potentiellt är illvillig, exkluderas. Andra administrativa aspekter som medföljer en webbportal med användarskapat innehåll, inkluderar användarsup- port och underhåll av tjänsten. Detta projekt skapades delvis för att utveckla en ny version av en redan existerande webbportal som an- vänds för annonsering av examensarbeten.

Målet med projektet är att utveckla en förbättrad version av den gamla webbportalen och försäkra att den nya versionen kräver så lite manuellt administrativt arbete som möjligt. Hur minimering av administrativt arbete åstadkoms för denna typ av tjänst ansågs vara okänt, därav valdes ett induktivt tillvägagångssätt till detta projekt för att under- söka hur mängden administrativt arbete minimeras för en webbportal vars innehåll skapas av dess användare.

Projektet resulterar i presentationen av en webbportal med ny funk- tionalitet med modifieringar inom olika aspekter beroende på det som efterfrågats av projektbeställaren. Visuella uppbyggnaden presenteras tillsammans med information angående vilka delar som återanvändes från den gamla version av webbportalen. Designval med fokus på minimering av administrativt arbete samt även generella designval som an- sågs viktiga, presenteras och motiveras. Slutligen drar studien slutsatsen att möjliga områden där det administrativa arbetet kan reduceras till stor del beror på kraven satta för webbportalen och att metoderna som användes i denna studie var framgångsrika i att identifiera de aspekter av administrativt arbete som kan reduceras eller elimineras från webbportalen som utvecklades i detta projekt. Slutsatsen dras även att tillräckligt sofistikerade automatiska system kan vara användbara för att reducera administrativt arbete för webbportaler med användarska- pat innehåll.

Nyckelord

Webbportal, Mjukvara, Administration, Minimera, Minimal, Exam- ensarbete

(5)

Building and hosting a web portal that publishes user created content comes with a fair share of problems and challenges [1]. Attempts to find solutions for these challenges are done through tests and discussion to through compromise try to achieve the best end result for both the users and the administrators of the web portal. It is important that the content posted on the web portal does not contain anything considered foul nor illegal, while also keeping the time for fresh content to be approved down to a minimum. In this project how to minimize administration work for a web portal is considered. The type of administration work considered consists mainly of user-related support, which includes approving/denying user submitted content, helping users with potential problems that arise and removing spam. Necessary maintenance work such as software modifications/updates or reinstallations in order to keep the service functioning as intended is also part of the administration work considered.

1.1 Background

In this paper, the type of web portal considered is a website where users can submit content that at some point may be publicly displayed on the website. This type of web portal can be used for many types of advertising, some examples are consumer-to-consumer sales, degree projects and job positions. There are also potential non-advertisement uses such as a portal for user-submitted recipes, user- submitted tutorials and short lessons on various subjects. Web portals with user created content all require administration and possibly require very strict rules to be enforced in order to make sure everything published in the system is consistent with its intended use and also legal[1].

1.2 Problem

The time required to maintain a web portal after deployment is preferred to be minimal. When building the portal, deciding on its functionality and structure are deciding factors in how well you can lessen the administrative work required to keep the portal running and working as intended. Having key parts planned ahead can be important in coming up with the best compromise to solve certain problems, while also being able to adapt to any desired changes to be made during the development. What a web portal should contain and how it should be designed, to both keep the support users need as well as other administrative work for the administrators to a minimum, was deemed unknown and therefore requires study.

(8)

1.3 Purpose

The primary purpose of this thesis is to provide information relevant to development of a web portal that has a requirement to require as little administration that can safely be allowed. The secondary purpose of the thesis is to create an improved version of an existing web portal, that was developed for the same client in a previous degree project[2][3]. The web portal will be heavily influenced by its precursor, which the new portal will replace. Before and during the development of the new web portal, steps will be taken to reduce the time needed on every encountered problem area that requires some kind of interaction from the administrator. Since all of the problem areas and their solutions cannot be known beforehand, a lot of decisions and discoveries will be made within the development iterations. After the development stage is complete and the web portal is in production, an in-depth analysis will be performed on how effective the methods and the solutions used were in making the portal require less administration, as well as give proposed changes for improvement.

1.4 Goal

The goal of this thesis is to create a web portal that, with none or only minimal administration, is used to advertise degree projects. The advertisement is carried out by different users who can be anyone that wants a degree student. The administration considered is both the administration done within the web portal and also the administration required to keep the web portal up and running. After the development is completed and the in-depth analysis has been performed on the data collected during the development process, helpful information about how to handle similar problems to those encountered will be defined and presented with an appropriate unit of measurement where it’s applicable.

1.4.1 Benefits, Ethics and Sustainability

The result of this thesis could benefit software developers by providing information on how a web portal with user created content can be designed to require as little administration as the application possibly allows, within its limitations set by the customer’s requirements. There is the additional expected benefits to the users of the software service stemming from the service receiving improved functionality, as well as to the current administrators who will have access to better administration tools and not require to give the web portal as much attention and time as previously. The methodology of the project itself entails a very low risk of breaking the ethical guidelines defined in the Sveriges Ingenjörer Code of Honour [4] . For the software service developed in the project, there are also very few aspects where Sveriges Ingenjörer Code of Honour could be broken, as the information stored

(9)

and handled is not of sensitive nature. There are however some ethical aspects in the administration of the product, because an administrator has to approve an ad before it is publically displayed. There is no guarantee that the administrator is objective and not sponsored by certain corporations. There are five dimensions of sustainable development that are important for an environment of innovation [5].

Three of these dimensions are based on goals for sustainable development defined by the UN [6].

These five dimensions (translated from Swedish) are:

• Customer-demands and market

• Motivation for environment friendly behavior(laws/financial motivation)

• Fair distribution of resources

• Equality in society and the workplace.

• Sustainable use of ecosystem-services and resources.

These sustainability aspects were considered when developing the product.

The goals that were set for this project regarding these aspects are:

1. Customer-demands and market

a. The system should be easy to maintain and easy to expand/modify. It should be well documented and have a dynamic code structure so that the service can stay in use and be adapted to the market.

2. Motivation for environment friendly behavior(laws/financial motivation) a. No goals regarding this aspect because there are no environmental laws

concerning this project.

3. Fair distribution of resources

a. The basic structure of the system entails a fair distribution of resources, as long as the administrator's decisions for approval/disapproval are fair.

4. Equality in society and the workplace

(10)

a. The application was deemed fair in terms of equality from the start.

The one source of inequality could be the recruiters themselves, but that’s not possible to avoid while fulfilling the functional demands of the application. Therefore there are no goals relating to this aspect except to keep it fair in terms of equality.

5. Sustainable use of ecosystem-services and resources

a. The type of service developed in this project does not use a lot of resources. The resources used are a computer (server) and electric energy.

One of our development goals is to make the application effective, which slightly reduces the amount of electric energy needed.

1.5 Research methodology and methods

In order to achieve a correct and well-founded result, research methods and research methodologies were chosen before any other work on this thesis was ini- tiated. There are two basic categories of research methods: qualitative research methods as well as quantitative research methods[7]. Quantitative research methods involve acquiring large data sets and using mathematics to test the hypothesis and evaluate the significance of the result[7]. With a qualitative research method, small data sets are commonly used. The qualitative research method involves understanding meanings, opinions and behavior[7]. In this thesis a qualitative research method will be used because a quantitative research method is not applicable to answering the thesis problem statement. An applied research method involves using data from the real work and applying it to solve problems and develop applications[7]. An inductive reasoning approach involves forming theories from observations[7]. For this thesis an applied research method is chosen for the development process together with an inductive reasoning approach. The applied research method was chosen as it was deemed the most suitable method out of common ones. The inductive reasoning approach was chosen as how to minimize administration for a web portal is unknown and thus data needed to be collected to form a theory on how to achieve minimal administration requirements for a web portal. An interpretative approach was chosen because what minimal administration work is, can not be purely objectively determined as it is subject to opinion. The methods chosen for data collection are participant observation and interviews as they were deemed most viable and useful out of common data collection methods considered.

(11)

1.6 Delimitations

The thesis was limited to only apply to software with similar functionality, which in this case specifically is a kind of web portal where users can post content to be publically displayed. The thesis was limited to not include advanced automation systems such as bot detection, unwanted link detection and spam detection for automatic administration, as these type of systems, especially the efficient ones, were deemed too complex for the scope of this project.

1.7 Outline

Chapter two presents detailed background theory relevant to web portals and dis- cusses research relevant to this thesis. Chapter three provides an in-depth description of research methodology and methods employed in this thesis and describes how the methodology and methods were applied in this thesis. This section also includes descriptions of methods used related to planning, modeling and developing of the web service developed in this thesis. Chapter four describes how data for the thesis was collected and presents the requirements specified for the web portal in this thesis along with their prioritisation. Chapter five provides a detailed description of software development process approaches used in this project. Chapter six presents the layout of the resulting web portal and the important design choices made in this project, along with their motivation. Chapter seven includes discussion regarding what was achieved and what was not. Chapter seven also includes discussion regarding future work related to this thesis that could be useful and factors that may have been missed or may vary.

(12)

2 Web portals and application development

The project for this thesis is about developing a web portal that requires minimal administration work. According to the client, the most important aspects of the administration work to be minimized is work related to user-support. Finding general guidelines or design patterns to follow that covers both the design part of the development as well as the user-support aspect of the maintenance after its live deployment, proved troublesome as the problem area is not very well explored and researched. The following section contains the relevant work found, explanation of which parts will be considered and why others will be dismissed, as well as some general background about the problem area the thesis undertakes.

2.1 Hosting of a web service

To publish content that should be publicly accessible through a web browser requires at least two things, a domain and a web server that hosts the web service.

The publisher has to have either direct or indirect control of the domain to have it setup to route any request that goes to the domain to end up at the web server hosting the service. There are normally at least a few different choices when it comes to choosing how and where the web service can be hosted. Outsourcing the hosting to an external company that provides all the necessities to have the web service up and running 24/7 is a viable option for most services. Outsourcing the hosting removes the need to learn what is needed to keep a server up and running securely and up-to-date. Outsourcing also comes with some drawbacks such as being forced to upload the source code where others potentially can access it, less customization about how and what the web server runs, having to choose between different price ranges depending on how much traffic is needed and the web service being unavailable due to forced maintenance by the hosting company.

Another option typically for enterprises or organisations is to have the web service hosted on their own servers, as having their own servers for other both internal and external services is common. A third option is to host the web service on your own web server consisting of a SoC(System on chip), which is a system with an integrated circuit containing all the components for it to work like an ordinary computer or server. Continued technology advances has made it possible to get relatively cheap, pocket-sized and energy efficient SoC that are powerful enough to handle the load generated by small web services[8]. One of the most common ones for this purpose is the Raspberry Pi, which steadily have been releasing new versions with increased performance[10]. The Raspberry Pi is compatible with running a full range of ARM GNU/Linux distributions[11], which makes both developing and transferring old services to one not require much work except some configuring.

(13)

2.2 Server-side programming language for web portals

There are multiple server-side programming languages to choose between for web development. Popular server-side programming languages used for web development include[9]: PHP, C# and Java. For web development with C#, ASP.NET is used, which is a set of technologies in the Microsoft .NET framework used for building web applications and also XML web services [12]. For web development with Java, Java Enterprise edition (Java EE) with a framework of choice is used, JSF 2 is a framework that comes bundled with Java EE [13]. For web development with PHP, there are a lot of different frameworks to choose between [14]. While web development with PHP can be done without using any software framework, using a software framework is a good idea because it simplifies the task of adher- ing to a pattern while implementing software [14], which is a key problem faced by software developers [14]. A software framework helps ensure correct design is not deviated from by providing separation between different layers [15]. When choosing a programming language, an important aspect to consider is the software developers experience with the programming language [16], to ensure that not a lot of time has to be spent on learning aspects specific for the chosen programming language.

2.3 Security of web portals

Security vulnerabilities in a web portal may lead to the web portal not functioning as intended after an attack and may even cause serious loss of data. Depending on the type of vulnerability being exploited, its effect on the web portal can en- tail extra administrative work, both to deal with potential malicious content or altered state of the application, as well as patch the vulnerability to prevent it from being exploited again. There are multiple security risks to consider for a web portal, below, the potential security risks and solutions considered by the project members are described.

A web portal with user-submitted content publicly displays the user’s submitted data. User-submitted data could contain various client-side scripting code [17, p. 66], or html that rewrites the structure of the website [18, p. 24]. A popular name for this type of code injection is cross-site scripting (XSS), which belies the fact that a successful attack does not necessarily involve JavaScript nor crossing sites or domains[18, p. 24]. Client-side scripting code is dangerous because it has access to the current page and all the information on it [17, p. 66], this means an attacker could use client-side scripting to steal a user’s cookie and imperson- ate a user or redirect to a malicious site [17, p.66]. A solution to this security vulnerability is to remove the ability for user-submitted data to be interpreted as code [17, p. 73]. A way to remove the ability for the user-submitted data to be

(14)

interpreted as html code is to replace brackets with their corresponding encoding, for example < can be replaced with < [17, p. 73]. However, a web portal with user-submitted content may wish to allow formatting options, such as bold text, which is achieved using html code. A solution to allowing formatting options while avoiding potentially malicious code injection is using BBCode to denote formatting [17, pp. 72-73], which entails, for example, using [b]...[/b] to denote bold text instead of <b>...</b>. The BBCode tags can then be substituted for actual html [17, p. 73] by a BBCode parser before displayed to users.

A cross-site request forgery(CSRF) attack leverages users identity by manipu- lating the victim’s browser into making requests on the attacker’s behalf [18, p.

81]. The request is thereby performed using the victim’s relationship to the site [18, p. 81], for example if the victim is authenticated as an admin user, the request will be performed as an admin user. A cross-site request forgery attack may be done using a malicious src value for an img tag and the src value does not have to be an image for a get request to be performed for the url specified [18, pp. 81-86].

Many HTTP requests will not have any negative effect on the victim, but this type of cross-site request forgery attack could be used to force users browsers to search for illegal content, or to "click" an advertising banner [18, p.86]. A cross- site request forgery attack may also involve tricking a user into opening some link that executes an action when the victim is logged onto the target site [19, p. 299].

The previously mentioned cross-site request forgery attacks work only with get requests, but there are also cross-site request forgery attacks that use forms(post requests)[20, p. 222]. A user may be fooled into submitting a form that seems innocent but is not, the form may be hosted on another site and use the action at- tribute to ensure the request reaches the target site [18, pp. 86-87]. A post-based csrf attack may also be done by submitting a form automatically using JavaScript [20, p. 222]. According to studied sources, a CSRF token is an effective coun- termeasure to cross-site request forgery attacks[18, p. 99] [21, pp. 32-33]. A csrf token is a pseudo-random value shared between a web application and the user’s browser, when the web application receives a request it verifies that the value is the one expected for the user’s current session [18, p. 99]. There is no way for a script from another site to get the csrf token value, because of the same-origin policy enforced by the web browser, which prevents code from one site reading output from another[22, p. 197]. It’s important to keep in mind that a Cross-site scripting (XSS) vulnerability will render CSRF attack defenses moot because the same origin policy does not restrict JavaScript served by the website with the form from reading the form values and setting http headers [18, pp. 93-94].

SQL (Structured Query Language) is a set-oriented programming language that is designed for querying and updating tables of information [23]. SQL injection

(15)

attacks target databases that use SQL statements and have been around for a long time [18, p. 107]. SQL injection attacks are used maliciously in many ways, including[18, pp. 107-108]: infecting a website with cross-site scripting or mal- ware payloads, to steal credit cards or other sensitive data, to execute commands on the hosts operating systems and DoS(Denial of Service) attacks (by executing inefficient queries). The SQL injection vulnerability arises because user-supplied data is interpreted as being part of the query rather than being data [18, p. 111].

Prepared statements can be used to protect the database from running arbitrary queries defined by an attacker [18, pp. 135-136]. Prepared statements do not necessarily from all malicious queries, for example, denial of service attacks through full table scans may be possible in some cases despite using prepared statements[18, p. 136], therefore it’s important to check for such possible exploit areas even when using prepared statements.

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for dis- tributed, collaborative, hypermedia information systems[24]. Essentially it’s the protocol used for data communication between web servers and web browsers.

Communication over HTTP is sent unencrypted [25][18, p. xv], meaning that anyone who may be able to get ahold of the packets being transmitted can view the transmitted data which may be sensitive, as well as opening up for the possi- bility of the a range of different vulnerabilities such as man-in-the-middle attacks [18, p. 247][26]. The Hypertext Transfer Protocol Secure (HTTPS) however is a communication protocol used for secure communication. HTTPS uses HTTP within a connection encrypted by either Secure Sockets Layer (SSL) or its succes- sor Transport Layer Security (TSL) [25]. By using HTTPS over HTTP you can ensure that the data sent between the server and client is encrypted, which protects against both man-in-the-middle type of attacks as well as eavesdropping or other kind of tampering with the data [18, p. 247] [26]. To enable HTTPS that will be trusted by most browsers, a security certificate must be obtained by a certificate authority (CA), who has their own steps to help protect users of the website issued the certificate [26]. While using HTTPS is always recommended, it’s especially important when the data being communicated contain sensitive information, so that the users’ privacy is well secured and everything sent and received is ensured to be correct [26] [18, pp. 143-144]. It is possible to use HTTPS without a valid security certificate provided by a CA, this will however, result in that the users will be warned when using the website that the certificate used is not trusted [27].

Running outdated software poses security risks since vulnerabilities that have been fixed in newer versions will still be present in older versions and could still be exploited by an attacker [28]. Security vulnerabilities may sometimes go unpatched, for that reason it could be useful to know if a program has had any known vul-

(16)

nerabilities. To check if a program has known security vulnerabilities, exploit databases such as the Common Vulnerabilities and Exposures (CVE) database [29] and exploit-db [30] can be used.

2.4 Content delivery networks (CDNs) for web portals

A content delivery network (CDN) is a platform of servers optimized to deliver content [31]. Content delivery networks are very widely used today, carrying nearly half of the world’s internet traffic [32]. A content delivery network acts as an intermediary between an application server and the users of the application [31].

Content delivery networks are commonly used for delivering web service content such as web pages, images, css and JavaScript files [31]. The content delivery network servers are dispersed across many locations and use cached files in order to respond to user requests quickly [31]. Without a content delivery network, a web service server must respond to every single user request, which results in an unnecessarily high amount of traffic between users and the application server.

If a content delivery network server is used, in most cases, the users of the web service will retrieve the files from an optimally located content delivery network server [31]. The application files being fetched from an optimally located content delivery network server instead of the application server entails a reduced load for the application server and a potentially improved user experience because the content can be delivered faster if delivered by a physically closer server[31].

2.5 Application development design patterns

The layered architecture pattern is one of the most commonly used patterns in software engineering [33]. The layered pattern involves dividing the software into layers, each layer being a group of modules with high cohesion [34]. The layered architecture pattern is a way of achieving separation and independence [35, p. 157]. The benefits of a well-designed layered architecture include [36, p. 14]:

greater reusability, more opportunity to improve or modify the overall implementation without breaking the system, increased understandability and modularity.

Disadvantages of the layered architecture pattern include [35, p. 158]: it may be difficult to provide a clean separation between layers and performance may become an issue because of multiple levels of interpretation as a service request has to be processed at each layer.

The model-view-controller (MVC) design pattern separates application code into three parts [37]:

• Model - Contains business logic.

(17)

• View - Contains only code directly related to rendering/updating the view.

All outgoing calls go to the controller, never to the model.

• Controller - Mediates between the model and the view.

An advantage that comes with the MVC design pattern is that data can change independently of its representation and vice versa [35, p. 155]. The MVC design pattern can be combined with the layered architecture pattern [38, p. 221].

2.6 Test types for web portals

There are many types of software testing, in this section a few types of software testing relevant to the web portal developed in this project are described. Accep- tance testing is a type of user testing where the user decides if the system should be accepted from the system developers and deployed [35, p. 228]. Browser compatibility testing involves testing different web browsers to ensure the pages both look and work as intended on multiple browsers[39]. To simplify browser compatibility testing, a web service called caniuse [40], can be used to check which browsers support certain website components. Another service that can be used to simplify compatibility testing by quickly generating the appearance of web pages in many versions of major web browsers is browserstack [41]. Functional testing involves verifying that the behavior of the software matches the functionality documented in the software requirements and specifications [42, p. 99]. Unit testing involves verifying that each unit of the system meets its specification [35, p. 31]. System testing involves testing the program as a complete system to ensure that the requirements have been met [35, p. 31]. Software security testing in the case of a web application involves finding security vulnerabilities in applications running on the website [43, p. 131].

2.7 Related work

The web portal service that will result from the thesis, is a new version of a web portal made in a previous degree project with its focus on improving the initial version of the web portal which was used at the time. The degree project report[3]

written for the development of the latest version will be used as an starting point during the initial phase of planning and designing the new web portal. In coherence with the client, the requirement specifications can be used as a start to find out what currently works for the client and what needs to be changed in the new version of the web portal to suit their needs. As the current visual design and layout is considered to be satisfactory, the ideas regarding those aspects will largely be carried over to the new web portal. The current web portal has some functionality that over the years has broken down and no longer works correctly

(18)

or at all. Without having access to the source code, preventing the same kind of mistakes and faults from happening can not be done by learning from his mistakes and instead has to be prevented by more stable implementation and design[44]

. The stance taken in the report about client-side validation[3, pp. 23-24] is something that will be dismissed, as the writer's view on the matter is incorrect according to all found credible sources[45][46].

Software maintenance can be defined by the following set of definitions[47]:

• The user-support view - provision of support to users,

• The bug-fixing view - detection and correction of errors,

• The need-to-adapt view - changes to software when its operational environment or requirements change.

While this thesis main focus is on the user-support view, this full set of definitions will throughout the project be considered as the three main categories of administration work. These definitions were deemed useful to this thesis, as it may be helpful to have a clear definition of administration work aspects to consider when attempting to find ways to minimize the amount of administration work required by the portal developed.

Part of this thesis revolves around identifying and finding solutions for a certain problem area, the administrative work that comes with this type of web portal.

Problem finding and solving in general is a well-studied field, giving plenty of different frameworks and methods to choose from and apply during the project.

The Problem Solving Method (PSM) created by Dr. Firend[48] is a framework used for identifying everything that in any shape or form can be seen as a problem and contains a process in stages for dealing with them. It is a quite general method and has been tried and tested in all sort of environments, proving its usefulness. As every part of the web portal has to be examined and thought about thoroughly, not only design choices that affect the administrative parts can be made using PSM, but also general design choices that affects the web portal’s functionality can be done at the same time.

(19)

3 Research methods and development process meth- ods

This chapter describes existing research methodology and explains the reasoning behind methodology and methods chosen for this thesis.

3.1 Research method categorization

Two basic categories of research methods are: Quantitative research methods and Qualitative research methods[7]. The approaches related to these categories are very different. Quantitative research uses numbers and statistical methods. Quan- titative research tends to be based on numerical measurements[49]. Qualitative research covers a wide range of approaches, but none of the approaches relies on measurements of large data. Qualitative research is usually focused on one or a small number of cases and tends to be concerned with a comprehensive account of some event or unit [49]. As using large data sets and statistical methods is not viable for the problem assessed in this thesis, qualitative methods were deemed more appropriate and therefore a qualitative research method was chosen for this thesis.

3.2 Philosophical assumptions

In the choice of qualitative research, researchers make certain philosophical assumptions, these assumptions consist of a stance toward the nature of reality[50].

The philosophical assumption is essential since it affects and steers the whole research[7]. Qualitative research can be positivist, interpretive or critical[51]. Pos- itivists generally assume that reality is objectively given and can be described by measurable properties which are independent of the observer and the observers instrument. Positivist studies generally attempt to test theory to increase predic- tive understanding. Interpretive researchers assume that access to reality is only through social construction such as language, consciousness and shared meanings. Interpretive studies generally attempt to understand phenomena through the meanings that people assign to them. Criticalist researchers assume that social reality is historically constituted and that it is produced and reproduced by people[51]. Considering these categories of assumptions, the interpretivist assumption was deemed the best fit for this thesis as people assign different meanings to what minimal administration implies.

(20)

3.3 Research methods

Research methods are used to provide a mean to conduct and apply scientific research procedures on the studied research-area. The research method chosen is to be applied on top of the research strategy, providing a higher level framework which support the usage of the later chosen research strategy[7][52]. There are numerous research methods, each with its own specific use case. They can however overlap or the research being conducted might not be a perfect fit for one specific research method. As this thesis will be conducted using the qualitative approach, the methods strictly used for quantitative research will be dismissed from this section as well as the qualitative research methods deemed to be not suitable at all for the thesis.

Applied research aspires to find solutions to specific questions or known problems of different kinds. Fundamental research has more of its focus on the theoretical, creating new theories or challenging old ones while generalising the for- mulations and hypotheses. Empirical research relies on real observations and experience, deriving knowledge from results of different experiments, observation and experience[7][52]. Based upon how suitable each research methodology was deemed to be for the thesis at hand, the applied research method is the one chosen to be used. As part of the thesis is aimed at finding solutions to concrete problems with the administrative part of the web portal, the applied research method fits perfectly to the thesis.

3.4 Research approaches and strategies

Different research approaches can be used when drawing conclusions about what is true or false. The inductive approach and the deductive approach differ greatly, while a third approach, the abductive approach, is a combination of both[7]. A deductive research approach entails developing a proposition and then designing a research framework to test that proposition[53]. A inductive research approach entails collecting data and developing a theory as a result of the data analysis[53].

Based on these definitions, an inductive approach was deemed more suitable for this thesis. As methods for minimizing administration for a web portal are unknown, data needs to be collected and analysed to form a theory on how to minimize administration.

The research strategies and designs are the guidelines used to ensure proper methodology during the organizing, planning, designing and conducting of the research[7, p. 6]. There are several different research strategies that can be used while conducting qualitative research, those found at least somewhat relevant to our method choices are described below with the explanation of why a certain one will be used.

Surveys can be performed either as cross-sectional or longitudinal. A cross-

(21)

sectional survey collects its data from a single point of time, while a longitudinal collects its data over a period of time. A survey can be used to collect data about a wide range of subjects, to examine for example relationship between different variables, attitude and stances perceived towards certain statements or to gather a generalized description of an unobservable phenomenon.

Using case studies entails conducting an empirical investigation to get a better understanding between a phenomenon and some real life context. Can be used for both qualitative and quantitative research.

The action research strategy is commonly used where the qualitative approach is the most suited, due to the often restricted sets of data that comes with handling the practical concerns entailed by certain problems. The strategy aims to find solutions or extended the knowledge of strategies, practices and environments.

Using the method involves iterative work in cycles, where you keep reevaluating the planning, actions to be made, analysing observations, evaluating the results made and perform critical reflection on the process made.

The exploratory research method can be used when the relationship between different variables is of interest, where finding as many relationships as possible helps to identify and define key issues and objectives. Surveys are commonly used to get a better insight into the problem.

The grounded theory method is used when there is a benefit of systematically collecting and analysing data throughout the research, with the aim of developing a theory that is built upon the collected data. The theory is inductive which benefits the development of theoretical accounts with general and broad features around different topics.

Comparing the different research strategies with the work to be done answering the thesis, gives a few different options where their respective attributes align with the needed qualities for the thesis. The one deemed most appropriate for this thesis is the action research strategy. Due to how few stakeholders there are with the administrative side of the web portal, the amount of data that can be obtained is quite low, which creates no restriction when using the method. The iterative work with constant cycles containing critical thinking and evaluating the current result and solution is something that will benefit in helping to create a more useful and better solution.

3.5 Data collection and analysis

As a qualitative research method has already been chosen, only common qualitative data collection methods were considered. The most common data collection methods used for qualitative research are Questionnaire, Case Study, Observa- tions, Interviews and finally Language and text[7]. The Questionnaire and Lan- guage and text data collection methods were disregarded as they were deemed

(22)

inapplicable methods for collecting data for this thesis. The Language and text data collection method involves interpreting meanings in text, documents and conversations[7]. Case studies typically combine data collection techniques such as interviews, observation, questionnaires and document and text analysis[54].

CaSCHENSUL, SCHENSUL, and LeCOMPTE (1999) define participant observation as "the process of learning through exposure to or involvement in the day-today or routine activities of participants in the researcher setting" [55]. To collect the data for this thesis a combination of Interviews and Participant observation was chosen as it was deemed most appropriate based on the definitions presented above. The observed participant is in this case considered the administrator and the analysis will also be performed by testing involvement in the administrator role.

3.6 Identifying administrative aspects

As previously mentioned, the administration aspect focused on in this project is primarily user-support related administration work that comes with a web portal with user-submitted content, but maintenance work(bug fixing or need to adapt) is also considered as administration work that should be minimized. In the case of a web portal with user-submitted content, the user-support administration work consists of helping users with various problems they may encounter and denying/approving user-submitted content if a denial/approval system is used. Be- cause no established method for identifying administrative aspects was found, a way of solving that problem had to be identified.

As a foundation to define steps that can be followed when identifying and creating solutions to the problem area, an adaption of the PSM (The Problem Solving Model) defined by Dr. Firend [48] is used. The PSM contains six iterative steps or stages, as well as six questions that constantly throughout the steps should be asked. The six questions, commonly known as the 5WH, are the following;

who, what, when, where, why and how. By taking the 5WH questions in mind throughout the thinking process of each stage, they will play a significant role in helping identifying key elements at each stage. Below the adapted version of the PSM will be described.

• Who - Person: personnel.

• What - Elements involved: Key points, issues, units of analyses

• When - Location: Places/Units/Departments/Member

• Where - Timing: including a series of events if applicable

• Why - Reasons and Causes: Why things happen

(23)

• How- Describe: the Process/Steps/Procedure about how something works, happen and/or behave.

Data Collection - The first step of the model is Data collection, which is the process of gathering as much information as possible regarding the problem area, which in this case is identifying and analysing anything that can produce workload for an administrator of the web portal. This process takes advantage of all the documents created before the start of the development, created both between the customer and the developers, as well as documents used by the developers. Soft- ware requirements specification, which describes all the requirements the client has on the service, use-case diagram documents, which describes most, if not all, use-cases of the service, greatly aid in the identification of possible problem areas.

For each requirement and each use-case the 5WH ’s should be asked to increase the rate and quality of the collected data.

Data Classification - The second step of the model is Data classification. The Data from the Data collection should be classified according to its various elements that are deemed to have impact that needs to be considered, such as; importance(priority), timeframe, location and possible unit of measurement. Once again the 5WH ’s should be considered for every element to help identify what impact it has on the problem area.

Analyses - The third step of the model is analyses. In this step all the elements previously identified are analysed in correlation with each other, to help identify how they affect each other and how potential changes would alter other elements due to their relationships. Using the 5WH model on this step is essential in aiding the analysis.

Planning - The fourth step of the model is planning. In the planning stage, attempts to find the optimal solutions for the identified problem areas and elements are made. What is considered optimal can change with time, which is why considering multiple different solutions and saving the ones dismissed for later can be of importance.

Implementation - The fifth step of the model is the actual implementation of the solutions that were deemed the most appropriate. It’s at this stage where faulty implementation can cause deficiency, flaws or ineffectiveness, hence why when as- sessing the effectiveness of the solution at a later stage, the prime starting point to look at the implementation stage and how the solution were implemented.

Measurement and Correction - The sixth and final step in the model is measurement and correction. This stage is a constantly ongoing process, due to the change of circumstances constantly can change. New elements can appear and the correlation between elements can change for different reasons, such as altered demands from the client. Both the success and failure of implemented solutions should be considered, and measured in the appropriate way for the element type. This will help find the underlying reasons for failure, and aid in the consideration of a new

(24)

solution for immediate or later improvements. The 5WH ’s are critical during this process to successfully determine what should be deemed successful or a failure.

3.7 Feature-driven development

A feature-driven development approach was chosen to be used throughout the degree project. Feature-driven development consists of five sequential processes[56], the five sequential processes are[56]:

• Developing an overall model

• Building a feature list - a feature list describes pieces of a system's functionality [57]

• Planning by features

• Design by feature

• Building by feature

In phase one, overall domain descriptions are prepared. Documented requirements are organized with proper use-cases and technical specifications[56]. In phase two, a list of features is created and features are grouped into feature- sets[57]. A “feature” is defined as a small piece of a system’s functionality which can be implemented in no more than two weeks[57]. In phase three, the features are analysed and the time requirements estimated, the feature-sets are then sorted according to priority assigned by the customer[57]. Phase four and five are iter- ated for a small group of features from a feature set. In these phases the work is a sequential process consisting of: design, development, testing[57].

3.8 The MoSCoW method for requirement prioritisation

The MoSCoW model (also known as the MoSCoW method [58, pp. 9-10] ) involves prioritising requirements by placing them in one of the following categories [59, p.

128] [58, pp. 9-10]:

• Must - requirements that must be fulfilled, on time.

• Should - requirements that must be fulfilled but that can be completed later.

Not as time critical as “Must” requirements.

• Could - requirements that are preferably fulfilled if the necessary time is available but these requirements are not critical for the project

(25)

• Will not - requirements that are not set for this project but that are relevant for the future

This type of prioritisation can be done to ensure that there is some degree of freedom in what is supposed to be delivered and when, as a safety precaution in case problems are encountered [59, p. 128]. In this project the time budget is not seen as flexible and therefore the MoSCoW model is chosen to be used to prioritise the requirements in the software requirements specification, in order to achieve some degree of freedom in what is delivered.

(26)

4 Data collection and requirements for the web portal

Before starting the process of coding the web portal, its functionality and requirements need to be set in order to be able to create the documentation needed for guidance while developing the web portal. To properly be able to shape the web portal and describe its properties in a concise format, data about the previous web portal and its usage had to be collected and analysed, to then be used to create the requirements for the new and improved version of the web portal. While the requirements are allowed to be altered during the development process and usually will, the documentation created from the data collection is essential, giving a foundation to start on and is able to provide an overview of the whole application to properly make architecture structure decisions long before its implementation.

4.1 Data collection

The first and very necessary step in the process is data collection. As stated in section 3.5, data is collected mostly through interviews and participant observation[55].

While the client who is requesting the web portal to be redeveloped arguably is the most important stakeholder, other stakeholders also need to be accounted for to be able to provide a well-balanced web portal with as few shortcomings as possible. The identified stakeholders are the web portal owner, the administrators, the publishers of content and the users that uses the web portal to search among the published content. The interviews conducted were of the unstructured type[7], still providing a lot of valuable data to consider when constructing the web portal and its requirements. Most of the data was collected during meetings with the client, who falls in under three out of the four identified stakeholders with the exception of the users, but could arguably also be included with the last one considering other administrators can alter and approve published content. During the first couple of meetings a second party was also present, who falls in under the last three identified stakeholders for the same reasons as for the client. Through these meetings a lot of valuable data is received to cover the basis to appropri- ately be able to design the web portal in all its aspects. During the meetings the participants demonstrated live on the current web portal how some of it looks and functions as it is today. Many point of interests were covered to provide as good of insight as possible into how the web portal currently is routinely used by them, as well as discussion on how parts of the web portal can be improved. The current routines for administering the web portal is gone through and the tools used analysed, to give enough data to create an equal or better experience that will require less effort. Some of the current functionality is broken and creates a lot of extra work for the administrators, such as when changing a state of a pub-

(27)

lishment, the text format can become completely broken and filled with newlines.

Together with the interviews, a recorded video of the administration process from the client owner was made for documentation, as well as admin access to the current web portal was provided, enough data is able to be collected and summarized to give a solid foundation upon which the web portal is to be built. From this the requirements described in section 4.2 were documented and accepted by the client who ordered the web portal.

4.2 Requirements specified for the web portal

As previously mentioned the MoSCoW model is used in this project to prioritise software requirements, this section presents the documented requirements along with their assigned prioritisation set according to the MoSCoW model. Many of the requirements were constructed in conjunction with discussion with the product owner. See the use case diagram in Appendix A for a summary of the most important requirements specified for the web portal.

4.2.1 Usability and design requirements

Table 1, shown below, contains the specified requirements for usability and design for the web portal developed in this project.

Requirement Priority(MoSCoW) Description

Simple design Must The layout of the web portal should follow the guidelines given by Google for website design [60].

WYSIWYG(What you see is what you get) editor

Must Formatting in publishments should

look the same way in the editor as they do after published.

Many available for-

matting options Could A user could preferably be given many formatting options when publishing a degree project.

English version of the

web portal Could Some of the users of the web portal may not know Swedish, therefore an English version of the web portal would be use- Improved search func- ful

tionality Could Improved search functionality could be

useful for students. The search function should search the full text and also the title.

Table 1: Usability and design requirements on the web portal

(28)

The improved search functionality requirement refers to the search functionality of the old version of the web portal, where a search is not done on titles or company names.

4.2.2 Compatibility requirements

Table 2, shown below, contains the specified requirements for the web portal in the compatibility aspect:

Requirement Priority Description Browser com-

patibility (functionality)

Must The web portal should function as intended in the 5 most common browsers according to w3schools statistics[61].

Browser compatibility (layout)

Must The web portal should not use components not supported by the 5 most common browsers and the website should look the same way in the five most common web browsers.

Responsive

design Could The website layout could be adapted to different screen sizes so that it is easy to use on phones and other common devices with smaller screen sizes.

Table 2: Compatibility requirements on the web portal

The browser compatibility requirements were specified by the product owner while the responsive design requirement is suggested by the project members. As previously mentioned, a web service called caniuse can be used to determine which browsers support certain web components.

4.2.3 Security requirements

A security requirement specified by the product owner is that if users click an external link on the web portal, they should first be redirected to a warning page where they are warned and have to press a confirm button to be redirected to the external page. The other security requirements were specified by the project members. Table 3, shown below, contains the security requirements specified for the web portal in this project.

(29)

Requirement Priority Description

SQL injections Must All SQL queries that deal with user-submitted data must be parameterized queries.

XSS(Cross-site script-

ing) Must All user-submitted data that may at some time be publicly shown must be sanitized to prevent code injection.

Cross-site request

forgery (CSRF) Must Cross-site request forgery attacks should not be possible on the web portal. CSRF tokens should be used to prevent these attacks

Encryption strength(if

accounts are used) Must Password encryption should be done using bcrypt or another widely used strong algorithm that has lasted long without being broken.

No old software with

known exploits Must Old software with known security exploits must not be used.

Confidentiality Must Personal information about users should not be accessible anywhere on the web portal without the appropriate login.

Administrator account password strength

Must Admin and root account passwords may not use the original passwords and must use strong passwords (at least 14 characters in length).

Warning on external links (if external links are allowed in submis- sions at all)

Must A user should be presented with a warning page before leaving the web portal if the user clicks an external link in user-submitted content

Https Should Https should be used everywhere on the web portal to protect user’s session data.

Table 3: Security requirements on the web portal

As previously mentioned, vulnerability databases such as the CVE database and exploit-db can be used to check if a program has known exploits, these databases are used in this project to determine whether a program has known vulnerabilities that could be exploited.

4.2.4 Functional requirements

This section presents the functional requirements specified for the web portal in this project. The functional requirements are divided into categories based on the user type.

In table 4, shown below, the functional requirements set for the web portal regarding what a student authenticated via KTH(Royal Institute of Technology)

(30)

should be able to do on the web portal, are presented.

Requirement Priority Description List degree projects

and filter by category/keywords

Must A student should be able to view approved degree projects and filter depending on category and keywords.

Book a degree

project Must A KTH student should be able to "book" a degree project, which hides it from public view for 3 days. A publishment is bookable unless the author chose to make it not bookable when publishing.

Unbook a degree

project Must A KTH student should be able to "unbook" a degree project they have previously booked.

Start degree

project Must A KTH student should be able to start a booked degree project, which sets the degree project in the "started"

status permanently unless changed by the user, author or an admin.

Finish degree

project Must A KTH student should be able to start a booked degree project, which sets the degree project in the "finished"

status permanently unless changed by the user, author or an admin.

Table 4: Functional requirements that should be accessible by a student on the web portal

The functionality described in first requirement, to be able to list and filter degree projects, is listed here because KTH students are the intended users, but that functionality is intended to be available for anyone, not just KTH students.

The point of a “booking” is to make a temporary reservation, so it’s important that the publishment is not publicly accessible during that time.

In table 5, shown below, the functional requirements specified for the web portal regarding what a recruiter should be able to do on the web portal are presented. The recruiters on the web portal are the users who post degree project advertisements.

(31)

Requirement Priority Description Publish degree

project Must A recruiter must be able to publish a degree project.

Remove/edit exist-

ing degree project Should A recruiter should be able to edit or remove their own publishments.

View history and republish previous publishments

Should A recruiter should be able to view their old publishments and republish them.

Change account information(if accounts are used)

Should If account registration is allowed on the web portal, the users should be able to change their account information.

Table 5: Functional requirements for a recruiter on the web portal

The editing/removal/history functionality described above is, of course, only accessible if the recruiter is authenticated. The editing capability requirement includes being able to edit any data in a publishment and being able to unbook users from their own publishments.

In table 6 below, the functional requirements specified regarding what functionality admin users should have access to are shown. The requirements shown in table 6 were all specified by the product owner.

Requirement Priority Description Edit/remove pub-

lishments Must An admin must be able to edit/remove all existing publishments.

Approved/deny

publishments Must An admin must be able to approve/deny publishments of unaudited degree projects (Degree projects are not shown publicly until approved).

List and manage booked, started and finished degree projects

Must An admin, unlike regular users, must be able to see booked, started, finished degree projects and edit them or remove the status.

Table 6: Functional requirements for a admin on the web portal

Unlike the editing for regular users, changes made by an admin are intended to be applied immediately and not require any approval.

A super admin user has access to all functionality a admin user has access to and more. Table 7, shown below, contains the requirements specified regarding what a super admin user should be able to do on the web portal.

(32)

Requirement Priority Description Handle administra-

tors Must A superadmin must be able to give and revoke admin privileges for users of the web portal.

Add/edit/remove

categories Must A superadmin must be able to add new categories, edit existing ones and delete existing ones.

Forbid accounts from doing actions that require an account

Could A super admin could be given the option to ban accounts from performing actions that require a login.

Table 7: Functional requirements for a superadmin on the web portal

An exception for the removal of categories is that it should not be possible to remove a category currently used by a degree project, because a degree project must have a category.

4.2.5 Documentation and testing requirements

The requirements regarding documentation and testing were mostly specified by the project members. Table 8, shown below, contains the requirements specified regarding documentation and testing of the web portal.

Requirement Priority Description

Testing Must The web service should be thoroughly tested according to a test plan.

Architecture and design documentation

Must The architecture and design should be thoroughly documented and include instructions for configuration and deployment.

User documenta-

tion Must The web portal must contain an information page where degree project practices are explained.

Information about

examiners Could The web portal could contain information about available examiners (at KTH).

Table 8: Documentation and testing requirements for the service

(33)

5 Development process and approaches

This chapter describes the development process approaches used and the chosen software along with the motivation behind the choice.

5.1 Feature-driven development

Below, the work conducted in each phase of the feature-driven development is described. During the first phase, use-case models for the web portal are constructed in order to make the functional requirements clear. Technical requirements are considered and non-functional requirements are documented following discussion with the product owner. During the second phase, a feature list is constructed from the requirements documented in phase one. During the third phase, in order to make sure the features were prioritized correctly, the features in the list are documented with a priority according to the MoSCoW model[59] following a discussion with the product owner regarding relative importance of the features. Sets of features were then assigned between the developers so that different parts of the web portal could be developed concurrently. Phase four and five are conducted in iterations where design diagrams are created before starting development on a feature, in the cases where a diagram is deemed useful, after that followed development and then testing. After passing the test phase, the set of newly implemented features are merged into the shared git repository ending its iteration and starting a new one where a set of other features are picked to be worked on by the developer.

5.2 Development and production environments

When choosing development environment, what the application is supposed to run on in production is greatly taken into consideration. The ideal scenario would be if everything created in the development environment flawlessly can be transferred over to the production environment without needing any changes.

The web portal will run on a Raspberry Pi 2 Model B, due to it being an available asset provided by the client as well as being the client’s desired platform.

The Raspberry Pi 2 Model B is compatible with running a full range of ARM GNU/Linux distributions[11]. By running the popular L.A.M.P(Linux, Apache, MySQL, and PHP)[62] setup as the web server on the Raspberry, everything done on a similar setup for development would be compatible to carry over as long as each part are of the same version or compatible with the versions installed.

The operating system chosen for the Raspberry is Raspbian, an Linux distribution based on Debian, which is optimized for the Raspberry Pi hardware. As it is well used and made specifically for the Raspberry Pi it is deemed a suitable choice for

(34)

both its performance and stability. The latest versions of Apache, MariaDB and PHP available to Raspbian are installed and the chosen programs are considered when choosing the development environment.

To make things simple when creating the development environment for all developers, creating a virtual machine with everything installed that is portable, makes sure that everything is identical pre-development and that everything working for one developer will work the same for others in most cases. As the project members had previous good experiences using ubuntu, it is chosen as the development environments operating system. The packages to install Apache, MariaDB and PHP were close to identical of those available to Raspbian, which result in no conflicts arising from running the web portal between the development and the production environments. For version control of the code and much of the documentation, KTH GitHub, which works exactly like the regular GitHub [63], is used.

5.3 Programming language and framework

For the web portal developed in this project, all programming languages described in section 2.2 are considered. For this project PHP is chosen, partially because there are a lot of frameworks for PHP [14] that simplify development and also because PHP is more widely used than for example Java for web development [64].

PHP being more widely used is beneficial for example if development is continued at some point in the future, because there is a greater chance of finding developers with experience in PHP than developers with experience in Java web development.

C# is not chosen because the project members lack experience with ASP.NET.

As previously mentioned, there are a lot of PHP frameworks to choose from[14], for this degree project the Laravel 5 framework is chosen, which is a newer framework that has quickly gained popularity for being clean, fast, easy to work with [65]. Since Laravel 3, it has become one of the most widely used PHP frameworks [66]. A framework that is widely used has been well tested because it has a lot users, this is deemed an important factor in deciding which framework to use, as it entails less bugs and security risks. Because of the reasons stated above, the Laravel framework is deemed a good choice.

5.4 Database and ORM

There are a plethora of different database software that can be used to store and access saved data for a web service. As the Laravel Framework is used for the web portal, its built-in functionality for handling database related communication is explored.

Laravel provides several packages to interact with databases, including regular

A web portal with

A web portal with

usersubmitted content

Creating a web portal and minimizing its need for administrative work

DANIEL WINGE

CHRISTER WINGE

Abstract

Abstract

Table of Contents

1 Introduction

1.1 Background

1.2 Problem

1.3 Purpose

1.4 Goal

1.5 Research methodology and methods

1.6 Delimitations

1.7 Outline

2 Web portals and application development

2.1 Hosting of a web service

2.2 Server-side programming language for web portals

2.3 Security of web portals

2.4 Content delivery networks (CDNs) for web portals

2.5 Application development design patterns

2.6 Test types for web portals

2.7 Related work

3 Research methods and development process meth- ods

3.1 Research method categorization

3.2 Philosophical assumptions

3.3 Research methods

3.4 Research approaches and strategies

3.5 Data collection and analysis

3.6 Identifying administrative aspects

3.7 Feature-driven development

3.8 The MoSCoW method for requirement prioritisation

4 Data collection and requirements for the web portal

4.1 Data collection

4.2 Requirements specified for the web portal

5 Development process and approaches

5.1 Feature-driven development

5.2 Development and production environments

5.3 Programming language and framework

5.4 Database and ORM