design of a generic administrator module and user ...ijsstr.com/data/frontimages/8_march_17.pdf ·...

International Journal of Social Science and Technology ISSN: 2415-6566 Vol. 2 No. 2; March 2017

100

Design of a Generic Administrator Module and User Component in Yii-based

Web Applications using the Concept of Observatory

1,2

Percy Okae, 3Amos David

1Computer Science Department, African University of Science & Technology (AUST), Abuja, Nigeria

2Computer Engineering Department, School of Engineering Sciences, College of Basic & Applied Sciences

(CBAS), University of Ghana, Legon, Accra, Ghana *Corresponding author email: [email protected]

Mobile: +233249990130

3University of Lorraine, Nancy 2, Nancy, France

Email :[email protected]

Mobile : +33608425064

*Corresponding author email: [email protected]

Abstract

This study implemented an administrator module in a Web application developed using the Yii PHP

component framework. This is to address the administrative needs of the application as a whole. A system

administrator should be able to log in to delete, view or update any record, and also moderate all comments.

For proper system integrity, the functionalities often exposed to the system administrator are often completely

different from those exposed to ordinary users. We want to keep these administrator functions completely

different from the rest of the application. This is normally accomplished by building a module to house the

administrator functionalities and features. Also, the developed system is meant to be user-centered and so we

implemented a user management component in the Web application. The concepts used in this study to

develop the underlying database of the Web application are observatory, competitive intelligence, and data

warehousing. The proposed model is such that the competitive intelligence products are aggregated into a

repository called an observatory which subsequently generates data for the data warehouse.

Keywords: administrator module, user management, observatory, competitive intelligence, data warehouse.


101

1. Introduction

A module is simply a mini-application running within the main application because it cannot run on its

own. Just like the main application in Yii, it also has its own model-view-controller (MVC) architecture

pattern. One foremost module of the Yii framework is the Web-based Giimodule which is automatically

generated in the configuration file once we build the shell of a Yii-based application from the command line.

For every Web application developed using the Yii PHP component framework, we can implement an

administrator module in order to facilitate site moderation by the system administrator. This is the premise

upon which a generic admin module is proposed so that it will be reusable in any application irrespective of its

subject matter. Similarly, a generic user component that identifies every user of the application, log in time,

specified functions, and access to type of data is also defined.

For this study, the underlying database of the Web application is developed using the concepts of

observatory and competitive intelligence as presented in Figure 1.

Methodology

Proposed model

Our proposed model is presented in Figure 1. In the model, the competitive intelligence (CI) products are

fed into the observatory mounted purposely as a repository of data for our eventual data warehouse (DWH).

Figure 1: Proposed model of research showing the critical concepts of CI, observatory, and data warehouse


102

The sources of data identified in this study are:

• Commissioned research;

• Internal staff;

• Third-party interviews; and

• Published information.

Once our data sources are identified, we subject the assembled data through a CI process cycle. Figure 2 is the

adopted cycle utilized in this research as they strictly show the most crucial stages of the CI process.

Figure 2: The CI process cycle adopted in this study

Datasets on the following can be contributed to the observatory by individuals who have them (NASA,

2013). These include but not limited to:

• The house numbers of houses in one’s community

• The social brackets that a particular community or household fallsunder

• The kinds of road networks in that community

• Environmental threats such as quarries, refineries, power plants, markets etc.

• Land cover or zoning

• Average population per household

• Proximity of a particular coverage area to a contracted organization’s premises

• Information on competitors

• Information on mergers and acquisitions

• Information on the attitude and work culture of field workers

• Customers opinions about the charges they pay to contracted companies

The above listed guidelines and any other workable ones can be compiled and fed into the observatory

and thus provide an idea of what to model and what to expect (Turnock and Gibson, 2001).


103

Creating the system module

The system administrator module is christened as “admin” and we generate all the necessary files using the

Gii module. To do that we navigate to http://localhost/mswproject/gii and choose the Module Generator from

the list of menu items on the Gii tool in Figure 3.

Figure 3: A screenshot of the module generator page

Once we input our Module ID in the text field shown, in this case “admin”, and click on preview, we can

see all the files that will be generated as seen in Figure 4.

Figure 4: A screenshot of the files generated under folder admin


104

Using the generatedadmin module in Web application

In order to use the generated files in the Web application, we have to alter the application configuration file so

that the new module admin will be accessible. To fire it up within our application, we need to alter the

application configuration file to include the admin module as below in bold:

---------

'modules'=>array(

// uncomment the following to enable the Gii tool

/*'gii'=>array (

'class'=>'system.gii.GiiModule',

'password'=>'yourpassword',

// If removed, Gii defaults to localhost only. Edit carefully to taste.

'ipFilters'=>array ('127.0.0.1',),

),

*/

'admin',

),

--------

Once this is done, we can access our admin module anywhere within the application. However, we also

need to organize the system RBAC authorization hierarchy such that it is only users with administrator

authorization who can access the admin module set up within our Web application. We implement this

hierarchy by defining the roles of various categories of users and restrict them as to what they can do and what

they cannot do (Winesett, 2010).

The logic for the implementation from the command line (CLI) is done using the yiic shell command. The

logical steps involved are to navigate to the YiiRoot as well as the Webroot then call the yiic shell command.

The YiiRoot is the folder where the Yii framework is installed whilst the Webroot is also the Web application

folder of our system development; i.e., where http://localhost/ resolves to. In our case, this is

C:/xampp/htdocs/mswproject/. We thus navigate to the Webroot as follows using the yiic shell command so as

to implement our RBAC hierarchy:

c: > cd/xampp

c:\xampp > cd htdocs

c:\xampp\htdocs > cd yii

c:\xampp\htdocs\yii > cd framework

c:\xampp\htdocs\yii\framework >yiic shell /xampp/htdocs/mswproject/index.php


105

By definition, a module is a mini application that runs inside the main application. It cannot exist

independently on its own even though it has all the features and functionalities that the main application has.

Our admin module is no exception and its interface is as shown in Figure 5.

Figure 5: Screenshot of admin console for site administrator

Figure 6 also displays the system message from the site administrator for any user who logs into or visits

the Web site.

Figure 6: Site homepage showing the time-bound greeting message from site administrator


106

Implementation of User Management Component

Although the auto generated code by the Yii framework contains a static authentication component, it is not

enough and a much secured security option for large and commercial Web applications that have many users.

The static username/password pair auto-generated by the framework uses demo/demo or admin/admin.

However, this option defeats the purpose of authenticating against the database tables which is more

secure(Ullman, 2013).

User Authentication and Authorization

User authentication is simply the process of ensuring that a user of our site has the all-clear to use the site.

This we can do by providing a registration feature within the site for all new users to register. Typically on

Web sites, this is accomplished by asking the user to provide a username/password or email/password

combination etc. if none of these is fulfilled; the user is then classified as an anonymous or guest user, in

which case access to various functionalities within the site are limited.

Besides authentication, user authorization will also determine whether a current user can perform a specific

task or not. For a fact, a user will not need to be necessarily authenticated to be authorized. For example, a

guest user can view a home page or a listing of items on a site without needing to login. Authorization always

determines whether a user is assigned the role of an administrator, co-administrator, authenticated user without

administrator rights etc.

The user component implementation of the site will proceed as follows:

• Create the physical user table in the database;

• Use Gii to generate all the required Yii files; i.e., User.php, the controller, and all the CRUD files; and

• Customize the generated code to authenticate against the user table as well as authorize access to the

site by modifying the controller files.

We first create a user table within our MySQL database application. The user table is as below:

CREATE TABLE USER (

id INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,

email VARCHAR(128) NOT NULL,

username VARCHAR (128) NOT NULL,

password CHAR(128) NOT NULL,

last_login_time DATETIME,

PRIMARY KEY (id),

UNIQUE INDEX username_UNIQUE (username ASC),


107

UNIQUE INDEX email_UNIQUE (email ASC)

)ENGINE=InnoDB DEFAULT CHARSET=utf8;

We next activate the Gii module of Yii to create our User AR class as well as the controller and CRUD

files by first logging in to Gii as we did in the generation of the module. However, in this casewe use only two

of the options for our purposes as those two will suffice our needs. These are the Model Generator to create

the User AR class and the Crud Generator to create the corresponding controller file as well as all the view

files required. If everything goes well, we get the following files generated (Yii Framework, 2012n):

• User.phpuser AR Model class (php code)

• userController.phpuser controller file (php code)

• _form.php

• search.php

• view.php

• admin.php

• create.phpuser view files (HTML and php code)

• index.php

• update.php

• view.php

This work uses localhost as the Web server and so our IP address is 127.0.0.1. The solution stack also used

for this work is the XAMPP solution stack which already has Apache, PHP, phpMyAdmin and MySQL which

we need for our project.

Subsequently, we build the shell of our Web application using the yiic webapp tool from the command line

as follows:

cd\xampp

c:\xampp > cd htdocs

c:\xampp\htdocs>cd yii

c:\xampp\htdocs\yii>cd framework

c:\xampp\htdocs\yii\framework>yiic webapp..\..\mswproject

To access the shell of our Web application, we navigate to our Webroot directory located at C:\xampp\htdocs

which is equivalent to http://localhost/mswproject/index.php/site/index and the resulting output is as shown in

Figure 7.


108

Figure 7: A screenshot of the shell of the Web site

In our underlying database, we create as a test case two users to test our design whether it works to

expectation. The following screenshots indicate what happens.

Figure 8: A screenshot of the create user form for user authentication


109

Figure 9: A screenshot of listings of users authenticated by the Web application

3. Discussion of Results

Our system is a Web application so we implement a system security so as to guide against system intrusion.

Thus user authentication and authorization is of prime importance here. Instead of sticking with the auto-

generated static authentication that Yii generates for us through the Web-based tool called Gii, it is best to

implement a system that authenticates a potential user of the Web application against the database as is the

norm for most applications. In Figure 6, we see that the user password has been encrypted against the user

table and hence against the system database to forestall a security breach. If a user whose password has been

encrypted in a particular order logs into the system and a match is found, then we say that the user has been

authenticated and access is subsequently granted.

4. Conclusions

A user management system component has been in-built into our application to forestall a system security

breach by encrypting user passwords. Any time an already existing user tries to log into the application, the

entered password is compared against the stored encrypted password and if there is a match, the user is passed,

otherwise he is denied.


110

References:

Ullman, L. (2013). The Yii Book, Developing Web Applications Using the Yii PHP Framework,

Self-published.

Winesett, J. (2010). Agile Web Application Development with Yii 1.1 and PHP5, Packt

Publishing, Birmingham, UK.

Yii Framework 2012n. Performance of Yii. Accessed on 20.11.2015 from

http://www.yiiframework.com/performance/

NASA, Earth Observatory. Retrieved September 25, 2013 from

http://earthobservatory.nasa.gov/Features/WorldOfChange/deforestation.php, 2013.

design of a generic administrator module and user ...ijsstr.com/data/frontimages/8_march_17.pdf ·...

Documents