Introduction
Coursework 2 is a culmination of previous tasks, rolled into one. It takes what was previously learned in the PHP lectures and packs them in a task that aims at the integration of our PHP scripts in forming a suitable web-program.
Overview
Coursework 2, was as follows:
Write a remote Web space management system suitable for handling Web site content of various types. It should allow a user to add and organise files to a personal Web area which is secured by password. Again, there will be a connected theme, to be announced in lecture time.
This program should include the following features.
(1) Your program should be written as PHP scripts. The user should be able to work with this program via a Web browser from any computer connected to the Internet.
(2) When your program starts, it should ask the user to enter a password and username, and not allow the user to access their Web space unless they know the password. Passwords should be stored in an appropriate MySQL database.
(3) Once allowed access the user should be able to:
(a) Make and delete directories
(b) Delete files
(c) Upload new files
(d) Only be able to access their own space, which should have space limits imposed upon it.
User data and passwords should be stored in an appropriate MySQL database or file system which the PHP script can access; you must consider security implications. There are no restrictions on the style of the user interface, although you should consider ease of use and design to be issues too.
Beyond the basic file management capabilities you could also consider adding the following:
- User preferences which alter the interface depending on who logs in.
- Auto-update of files so when a Website has been updated locally all new files can be uploaded.
- Support for mobile device (‘phone or PDA etc.)
Storing Files: File System vs. Database
When it comes to storing files I came across the old debate of whether to store your files on the server file system or directly in your database. I found good and valid arguments for either solution, which I have presented below:
File System Pros
Scenario for storing files on your file system and their location in a database
- The ability to serve the files as static
- No database coding is required to access the files
- The files could be stored on a separate location to optimise performance
- Reduce bottlenecks in your database
- A database is at the end of the day, still on your file system
- Easy caching
File System Cons
- Files are easily in view in your file system
- File have no real relations between them
- Extra scripts need to be made to maintain integrity between the files and their locations on the database
- Permissions to store files on your file system is needed
- Easy association between the files and their owners/properties
- Features like auto-sorting can be easily implemented
- Data is stored in a single location, making it easier to backup or move to another server
- No easy access to files through simply file system browsing
- General notion is that the database is generally slower performance-wise
- Lack of easy access to files
- To backup your files, all the database needs to be copied
Database Pros
- Easy association between the files and their owners/properties
- Features like auto-sorting can be easily implemented
- Data is stored in a single location, making it easier to backup or move to another server
- No easy access to files through simply file system browsing
- General notion is that the database is generally slower performance-wise
- Lack of easy access to files
- To backup your files, all the database needs to be copied
Database Cons
- General notion is that the database is generally slower performance-wise
- Lack of easy access to files
- To backup your files, all the database needs to be copied
Decision
While looking into the matter, I also chanced upon a paper which researched and compared the idea that: files smaller than 256kb are faster to store in a Database and files larger than 1Mb are faster on a file system. The research analysed the performance with different file sizes and found the notion to be generally true, albeit less significant difference at the lower end. In general, large amounts of data to be transferred and stored, mostly above 1Mb are better stored in the file system, favouring performance.
For the purpose of the simple web-space I opted for a database solution and limiting the users’ maximum file size to 1Mb. Have a 1Mb limit is a fair assumption, since most documents and images are never larger than that. This will store my files in a central location and make them less susceptible to easy attacks, such as file system browsing. On the other hand, I am aware that they are now more subject to direct SQL attacks.
http://research.microsoft.com/pubs/64525/tr-2006-45.pdf
http://stackoverflow.com/questions/211895/storing-documents-as-blobs-in-a-database-any-disadvantages
http://imar.spaanjaars.com/414/storing-uploaded-files-in-a-database-or-in-the-file-system-with-aspnet-20
http://stackoverflow.com/questions/561447/store-pictures-as-files-or-in-the-database-for-a-web-app
Working Environment
A description of my working environment while developing this web-program
- Developing on Windows 7 machine using Eclipse with PHP plug-in
- Running Ubuntu 10.10 on a VMWare Virtual Machine
- Xampp for Linux (lampp) installed on Ubuntu
- Assigned a separate IP address for Ubuntu VM in my home network
- Accessed pages from Windows 7 to simulate client accessing server (different IPs)
- Testing browsers: Google Chrome 11, Mozilla Firefox 4, Microsoft Internet Explorer 9
MySQL Tables
The first stepping stone for this coursework was to create the tables needed in our servers’ MySQL database. I identified that two tables were required: a user table and a file table
User table
- User ID
- User Name
- User Password
- Creation Date
File table
- File ID
- File user name
- Name of file
- Type of file (MIME info)
- Size of file
- Content
These tables were created on the servers’ MySQL database
Register
The basic structure of the PHP code when a user attempts to register is shown below:
- Check for any black fields
- Check that both passwords given match
- Connect to database
- Check if the username is already in use
- Add slashes to the password (reduce SQL injection attacks)
- Encrypt password
- Insert the data into the database
- Return message to show completion
- Redirect to Log In page
The PHP code is shown below:
followed by a screenshot of the register form
Log In
The code for the Log In page, is structured as so:
- Check that the user has actually filled the form
- Check if username exists
- Connect to database
- Get password for that username
- Stripslashes of entered password
- Encrypt entered password
- Match encrypted passwords
- Create Session if all successful and redirect to phpMainPage.php
The PHP code is shown below:
followed by a screenshot of the Log In window
Sessions
To prevent users from simply entering the URL of a PHP page and accessing it, a method for authenticating the user is required: hence PHP Sessions. A PHP session allows us to save information for later use on the server. Thus, it also enables information to pass from one PHP page to another.
For this task I intend to use the Session to:
- Store the username and therefore by checking that it exists in each page, we can now verify if the user is indeed, a registered user, and is authenticated to visit that page or perform that action
- Store notification messages, such as “Deleted file info.png”
- Store the size percentage still available to the user
The PHP code that precedes every page to authenticate the user is shown below:
Uploading Files
Before deciding on how to upload a file, some rules had to be made. It was decided that each user will have a space of 50mb each. Also, each file that is uploaded must not exceed 1Mb in size. When looking at the types of files to be allowed, I decided to allow:
- .pdf – Adobe PDF
- .doc, .docx – Old and new Word Document format
- .xls, .xlsx – Old and new Excel Document format
- .ppt, .pptx – Old and new Powerpoint Presentation format
- .jpeg, .png, .gif – Image types
The proceedings of uploading a file are outlined below:
- Check the remaining space available
- Get the name, type (MIME) and size of the posted file
- Check that the size of the file does not exceed 1Mb
- Check that the type of file is of an acceptable format
- Check the server for magic quotes
- Addslashes
- Open file
- Read file
- Apply addslashes
- Close file
- Connect to the database
- Write query that will insert the name, type, size and content of the file into the database
- Execute query
- Close the sql connection
- Notify the user
Actual PHP script for uploading a file:
followed by a screenshot of a user uploading a file and receiving an appropriate confirmation message
Deleting Files
Deleting a file is fairly similar to the other procedures:
- Connect to database
- Form the query according to the file chose for that particular user
- Execute query
- Close connection
- Notify the user via the session
- Redirect back to the main page
Script for deleting a file:
followed by a visual confirmation of a user deleting a file, in this case, an image
Downloading Files
When I got to the part of writing the script to download the file from the database, it proved to be quite problematic. The first part of the process was the same as the deletion of files, but I couldn’t quite get the “serving the file to the user” part quite right at first. After quite a bit of research and digging, with many false positives I found a working solution.
The process is similar to the deletion of files, with the exception that the file sent to the user through the use of “header("Content-Disposition: attachment; filename=$name");”. The size and type of the file are also passed to the header to instruct the browser on what to do with the passed file.
Script for downloading the file:
followed by a screenshot of a downloaded file in Google Chrome
Webspace Size Limit
The function for checking and limiting the amount of user uploads was stored in a separate PHP page. Giving the amount left in percentage seems like a good idea to further guide the user.
- Connect to database
- Write query to get the size of all the files of user given
- Execute query
- Put each row of size into an array
- Add all the values of the array and calculate percentage from 50Mb
- Add the result to the session
PHP script for the space remaining check:
Main Page
The main page is intended to be the “central control panel” for the user, were they can upload/delete and download their files while getting the appropriate information such as notifications and current space remaining all at a glance. This undoubtedly is designed with user usability in mind.
The basic concept includes:
- Displaying the name of the user logged in
- Adding a Log Out button
- A notification area (to display a message when a file is appended)
- A button to select a file for upload, and one to upload it
- A percentage metre of the space available
- A list of all the files the user has, each having a download and a delete option
Getting the filename list was quite straight-forward; done with an SQL query and the list of files stored in an array. Being quite new to PHP, I encountered a problem with the idea of generating a table for each filename, adding a delete and download button, and having the buttons trigger the action.
Generating the table was not the issue and it was done by looping through the filenames and issuing html code for each filename. The problem came when I tried to trigger the PHP script by writing a redirection in the “onclick” property of the button. It seemed logical to do so, but in fact I was totally wrong, since PHP is a server-side script and you cannot simply call a page from within the HTML.
PHP typically functions by packaging your information into a form and sending it to the server. Building on this, I transformed my table for containing the filenames and buttons into a form. Having done so, I stumbled upon another hurdle. I was looping through the form generation and assigning a hidden value having name be an “echo” of the “filename[i]” from the loop. When the button is actually called, “i” actually contains the number for the last entry of the array. Therefore, effectively, the name of the last file was always being sent.
After a fair amount of reading I stumbled upon a similar issue posed by a fellow learner of PHP. The proposed solution was to actually add the “filename[i]” as an associative array in the name property. This was successful and I got rid of the hidden value and added a “Download[filename[i]” idea to the name property of each button.
When I attempt to now download and delete a file by clicking their respective buttons, the action and its’ filename are posted to phpEditFile.php were they are analysed and directed to the respective functions.
The PHP script for the Main page is shown below:
followed by a screenshot giving an overview of the Main Page
Future Improvements
- Labels
- Trash
- Colour Scheme
- Date Uploaded
Given the certain time constrains, and the task being an academic project, there were some functions that I wanted to add but couldn’t. First off an option to place a label for a file would have made the experience more Gmail-like and intuitive. Another feature I wanted to add was a hint of user customisation were the user can select a colour scheme for their Main Page, and the colour scheme being used every time the user logs in.
At the beginning I overlooked the need to save the date of when a file was uploaded. This would have allowed a sort by date option. Apart from these, with some more time and some JavaScript the web-program can become much more appeasing to the eye. It serves it function but somewhat lacks in eye-candy.
One more future improvement would be to eliminate the page refreshing. After some research I learned that in order to do this, one must make use of AJAX. It is now on the future, to-do list.
Conclusion and Reflection
Upon further consideration, the decision to store the files as in the database rather than directly to the file system might not have been such a great idea, weighing the respective advantages and disadvantages. For a simple, limited solution, the database option is a safe bet, but if you intend to scale out in a real environment, the file system option is much more suitable. If I had to start the task again, I would probably go for a file system approach. The database approach was an early decision in this task, which reciprocated throughout the whole task.
All in all, the task was a good learning exercise. Applying the various concepts picked up during the lectures and joining them together into one task, accompanied by independent research to resolve particular problems, was a good thing. A steep learning curve with any new concepts ensued, which undoubtedly took its’ toll at some times, but the end result was good.
References
W3Schools for PHP, CSS and HTML reference
StackOverflow Forums
