Server

Some quick notes:

• All the usernames and passwords were set to username: admin and password: q1w2e3r4, for the purposes of this assignment.
• The site's folder is set to be tomcat\webapps\musicblues.
• For setting up this assignment's modules, the lectures' slides and the directions inside the specification were closely followed.
• There was a problem in the encoding format of Tomcat's log files (unknown characters instead of Month and am/pm). Maybe because some system variables were still set to Greek Local (I have checked that in the Control Panel but the general settings were correct). I have corrected the problem manually in the submitted logs (logs.zip).

Setting up, configuring and customising Tomcat

Apache Tomcat 6.0.16 was installed in Windows Vista Business OS. Tomcat uses JDK 1.6.0_02, Java(TM) SE Runtime Environment (build 1.6.0_02-b06).

Installation

During the installation process, the default port for HTTP was set to 80. Tomcat was not installed as a service that starts automatically on the system startup because the system is already overloaded.

Tomcat configuration

• Content Negotiation. Using the guidelines and the files provided in the specification of the assignment, content negotiation was applied on Tomcat. The delivery type of the pages in Firefox is application/xhtml+xml and the encoding is UTF-8. Pages display OK in Internet Explorer.
• The site was moved to another directory inside Tomcat (webapps/musicblues). To do that the conf/servel.xml file was edited (changed the docBase attribute of Context tag which stands inside Host tag from ROOT to musicblues). The site runs smoothly from / not from /musicblues.
• Pages and directories password protection. To do that I followed the directions of this page. Directories /db and /test are protected from unauthorized access (access allowed only to username: admin and password: q1w2e3r4). In order to apply this, the MemoryRealm standard plug-in was used (no need to use a database). MemoryRealm is a part of Realm (database for handling users and their roles). The users with their respective roles are defined in the conf\tomcat-users.xml file. Then a security constraint that specifies the protected paths (directories or files) and the user roles that are allowed to access them is added to the internal WEB-INF\web.xml file of the site.
• Pages Encryption (HTTPS with OpenSLL). To do this I followed the instructions of this page. I created a keystore from scratch (keytool -genkey -alias tomcat -keyalg RSA) and moved it into tomcat\openSSL folder. I added to the conf\server.xml the context parameters for the OpenSSL certificate. The port for HTTPS was changed to the default 443 together with the redirectPorts of the other Contexts. To force the use of HTTPS on the directories or pages that were password protected or performed an action, an additional user data constraint with confidential transport guarantee was added to the internal WEB-INF\web.xml file.
• Tomcat service under Windows Vista OS. A service in Windows has three basic startup types (Manual, Automatic, Disabled). One way to set Apache Tomcat's startup type is to right click My Computer icon on the Desktop, then click Manage, then on the left panel of the new window click Services and Applications, and then Services. At last we are able to see all the services of our OS. We find the service named Apache Tomcat, go to its properties and choose one of the basic startup types (Manual if we want to start Tomcat manually, Automatic for running when the OS starts, and Disabled in order to disable the service). For those who use the configuration tool of Tomcat there is an easier way to do the above. Just in the general properties tab, set the startup type to manual, automatic or disabled. Using this tool we may turn on or off (start, stop, pause, restart) Tomcat on a specific moment without changing the initial startup configuration.

Integration of Tomcat with other technologies

JSTL setup

First, conf\web.xml file was checked to find out whether it had version 2.5 (this version of Tomcat has 2.5 by default). Then, Jakarta Standard 1.1 taglib was installed following the instructions on the database lecture slides. Folder WEB-INF\lib did not exist, so it had to be created.

Setting up the database (McKoi)

The main steps were:

• Copy mckoidb.jar file (database driver) to tomcat\lib directory.
• Create tomcat\database directory and put db.conf file in it.
• Edit db.conf as described in the specification.
• Add a new context with a resource element describing the database parameters to the conf\server.xml file.
• Publish this resource by adding the relevant elements to WEB-INF\web.xml file.

Database creation and maintenance

• A database was created by executing the relevant command provided in the specification.
• Using the source code of the specification, plus some additions of my own, I ended up with one file (can be found under db directory, site\db\index.jsp) that provides a web interface for database maintenance including some basic help about SQL commands taken from the McKoi documentation. It took some time, but now the this page is XHTML 1.1 valid. I know that is not proper to have everything in one page (request, action, result) but it was a fast and convenient way for me (as I did not care about the browsing history) to see the results in same page. This page is for administrative purposes and has to meet the administrator's way of approaching things!.
• The directory is locked (username: admin, password: q1w2e3r4) and HTTPS is used.

Testing the modules

Page site\test\index.jsp contains some tests for proving that everything runs smoothly. Most of them were taken from the lecture notes. There are different tests for each module (Java, Scripting, JSTL, Database, and Java Class Access to the Database) and one test that performs all the previous tests (apart from the last one) in one go. In order to access the database through a Java class and hold the values of the attributes stored in the database in objects of that class, the test\test_db_java_access.jsp and db_test.tag files were used together with the Java class User. Class User is located in site\WEB-INF\com\musicblues\login and it is included in the WEB-INF\lib\login.jar. The test directory and pages are locked (admin, q1w2e3r4) and served using OpenSSL encryption.

Tools Used

The application used for writing pages (JSP, XHTML, tags), CSS, (Java)scripts, and SQL was jEdit 4.3pre12 (with its XML plugin).

Programming

Custom tags

Plenty of custom tags were used. All the custom tags are located in the site\WEB-INF\tags directory. Apart from using tags to represent the site' footer and part of the site's header, many tags represent a block on the right or left side of the site. This transforms the static block code to a widget that can be included in different pages or have different behaviour depending on the parameters of the page. In addition, there are tags for executing SQL queries (parts of action pages).

Implementation of a registration page

The files used for user registration are register.jsp, register-action.jsp, and db_user_register.tag. A database table named Users with fields (forname, surname, username, password, email, yearOfBirth) was used for storing the users. register-action.jsp takes the information from register.jsp, and performs validation checks to the data. If the data are valid and complete then they are passed to the database using db_user_register tag. At the end register-action.jsp redirects to page register.jsp and informs it about an error (relevant error code) or a success. register.jsp, in turn, informs the user whether his registration was successful or not. If not, then register.jsp maps the error code to an error message and informs the user what exactly is wrong.

register.jsp remembers some of the fields that the user has filled in, in case of an unsuccessful registration, so that the user does not have to retype them. Javascript validation script was not applied to this page (for the purposes of this assignment - control derives from the server only).

register.jsp contains a small implementation of a numeric captcha box; two (pseudo) random numbers < 10 are displayed in string format (by using a HashMap<Integer, String>), and the system asks from the user to type their sum in a numeric format. Before passing the data to register-action.jsp the numeric sum of these two numbers is calculated and passed to a hidden input (in order to perform validation in the action page). It also uses a combination of JSP and XHTML to display all the years from 1910 to the current year in a select form.

register.jsp and register-action.jsp have been set to use https. Apart from that hashing is performed to the passwords, before passing them to the database. The code used for this purpose is a result of multiple web sources. It uses MD5 to hash the passwords. The query in db_user_register.tag is performed using ? to enhance security. I would like to add an email verification module but I faced some problems (see next section).

Implementation of user authentication

The files used for this are right_login.tag and login-action.jsp. User types his username and password in the relevant form (upper right corner), and then presses the login button. The request is sent to login-action.jsp page together with the page's URL (hidden input field; this is done because we do not know the URL of the page that the user may use to login). This page will convert the typed password to its MD5 hashed equivalent, and then will query the database searching for a user record with the specified attributes. If it does not find a record then it returns an error parameter to the page it was called from. An Invalid username or password message is displayed under the login button. If it finds a record, then the user is logged into the system, and the login form changes to another widget that welcomes the user and displays a Logout button. If the user presses the Logout button, then everything turns to the initial state.

Send email from a form using JavaMail API

contact.jsp and contact-action.jsp pages using the site\WEB-INF\mail-1.4.1.jar (JavaMail API from Sun) try to send an email to a preconfigured email address of the site from a visitor. This does not work (probably need a mail server to work)! The page will try to send the email but after a while it will fail to succeed. Anyway, not a big portion of my time was dedicated to this module. I want to mention that contact-action.jsp code is a result of searching (mostly).

Jars created but never used

I created two .jar files (site\WEB-INF\lib), one for testing Java Class access to the Database (login.jar) and one for producing hashed passwords in a more convenient way (hashMD5.jar). The truth is that I used login.jar for testing purposes and that I never user hashMD5.jar (because there was not enough time to do it - I have already exceeded the time limit I had set for this assignment).

What took me a long time

• Use OpenSSL with Tomcat. I got lost a lot of times but in the end everything worked fine!
• Find out how exactly I should use Realm to password protect folders. At the beginning, I thought that the HOW TO documentation of Apache needed a lot of experience to read (so I avoided reading it), but after setting up OpenSSL and Realm, I figured out I was wrong.
• The creation of multiple tags that now can be used as widgets filling up the left or the right column.
• This simple line of Java code: pageContext.setAttribute("var_out",var);. I wanted to use the value of a variable set in Java code inside a JSTL tag.
• The implementation of registration and login modules.
• Simple, little stuff, popping up every minute that caused hundreds of web searches or researches and took a lot of time.
• It is not to be marked, but this report took a lot of my time.

What I am proud of

• That I managed to set up OpenSSL! Nothing great of course, but I was proud of it.
• For the whole look and feel of the Music and the Blues site. It needs, of course, a lot of work (and more people) to become something usable.
• For the registration and the login module.
• With the application of custom tags, the blocks on right and left sides became real widgets. Extending the website, an administration page could be implemented, where the administrator will be able to decide which widgets will be included in each page as well as their exact position (in a minimal scenario three database tables are needed: one for the widgets, one for the pages, and one for the page-widget couples).
• That I learned a lot from this unit! [end note]

Conforming with the standards

All the pages meet the XHTML 1.0 W3C standard (tested using Firefox Validator plugin) and all the CSS files meet the CSS 2.1 standard (tested using W3C CSS Validator). The web site behaves smoothly on Mozilla Firefox 2.0.0.14, Internet Explorer 7.0.6000.16643, and Opera 9.25.