Final thoughts...

A full 6 months have passed since we started this module together during which although we only met a couple hours a week we managed to cover a great deal of topics and complete various workshops. This post is intended as a wrap up for this module which will go through most of the material we went through.

HTML/CSS - This was our first session together, all of us knew at lest the very basics of HTML and CSS and while the session was very informative it was more of a familiarization session where we introduced each-other and started getting used to the module. I still remember this first post we had to write and how many hours I spent re-writing same sentences over and over again.
 
JavaScript - Out first assignment in this module was the java script running man, experimenting with a language I never dared getting close to because of all the misconceptions surrounding it from compatibility issues any lack of   standards proved to be very informative. Although there are real compatibility issues with JavaScript most can easily be overcome by following proper guidelines and design patterns available over the net.

PHP -This was out second task for this module, we were all asked to design and develop a web-space management system where users would be able to upload and download files securely through a browser. This was

SecondLife - I must admit this part of the module would be the one I disliked the most, spending time in a virtual environment with graphics like they're 5 years too late seemed way too daunting. The scripting sessions were interesting but again we were developing in an environment none of us were interested in. If I had to learn a scripting language I would have rather learnt something which might become useful later on in my carer. Virtual world will someday become the norm but I'm sure it will not be in form of the current second life implementation. One thing is fore sure you will not be finding my avatar roaming the second world any time soon

HTML5/Mobile Applications - During these sessions we explored various features that are already available though current production browser versions such as the geo-location feature on Chrome and mobile devices.


Online Social Networks - This was an informative session about social networks, we are also now all grouped up in Google+ circles as a result of that session.

Cloud Computing - This was the topic we covered during our final session, we discussed what the "cloud" actually means and the various advantages and disadvantages to distributed computing as well as the security issues relating to "the cloud".

Just writing this blog post makes me wonder how we actually managed to do all that in just a couple of months, but we did. I'm sure every one of us would agree that it was all interesting and informative.

Finally I would like to thank our tutor Jeremy who presented this module in an interesting fashion enriching each session with the knowledge gathered throughout his own career in the IT industry.

Online Social Networks

Online social networks have been around since the first time I logged into the internet, it is part of us humans that want to build social networks be it online or offline. On reading about the subject it was amazing to what lengths people would go through just to pass a simple message around.

For as long as I can remember I have been dragged from one online social network to another, I'm not a fan of any of them and quite frankly can do without any of them. The only reason I join as well as quit is because all my friends do.

The first social network I was ever a part of was IRC (Internet Relay Chat) based which at that time server the purpose just fine. It allowed us friends to identify each other, have mult-person conversations and speak as privately and publicly as we wanted. Next MSN Messenger started catching on, people where all shifting from IRC to MSN which allows you to identify yourself securely to your friends by your hotmail.com email account as well as accept/reject/block anyone you would want from your contact list. In my opinion the real reason people moved from IRC to MSN was because it looked "pretty". characters such as :) where being automatically transformed into smiling face emoticons and everyone was allowed to select their desired backgrounds and fonts.

Then came all the web-based social networks such as mySpace, hi5, facebook and now Google+, all trying to gain as much of the world's internet's population hostage to the multitude of features (mostly useless) to ultimately generate advertising revenue.

In my opinion the only reason why social networks have ultimately taken over most of the internet's traffic is because they're viral in nature. If you create an account at any of these sites you want your friends to be there too otherwise it's useless, on inviting your friends to join the network you have contributed to the viral nature of these networks and that is why the most successful ones grow exponentially and die off fast.

One could go on forever about the pros and cons on online social networks and would never end up with a definitive answer, yes we need social networks because they fulfill some inner human "feature"which makes us want to be a part of something but yet exposes some of our worst fears about privacy. 

I have spend the majority of this post explaining my personal experience with online social networks yet not made any reference to anything relating to web technologies. I Believe that most of the latest web-technologies we have today are there because of social networks. The internet has been around for decades now but prior to the last 5 years all web-pages were simply that just HTML pages. Social networks have developed on the same technologies (HTTP, HTML, JavaScript) to come up with something as dynamic as a desktop application. AJAX has been technically possible since HTTP and JavaScript were available yet very little tried to implement it prior to the social network boom. That is one thing we should at least all be thankful for :)

Mobile application development

This week's session was dedicated to mobile application development, since we only had a couple of hours to work with we decided to work using technologies we were all familiar with, web technologies. It would have been futile anyway if we had to decide which technology from which brands of smart phone manufacturers we should cover, everyone would have come up with their own personal preferences and it would have ended up being a long session with arguments as to why one technology is better. NOT the intention behind the session.

At this point I was thinking well we all know how to create websites so most probably we will be spending the session creating web-pages designed for smaller screen. I'm sure it would have been interesting but it wouldn't have done justice to the title "mobile application development", a web-page designed for a smaller screen is not a mobile phone app, it's just a tiny web page.

Fortunately enough I was wrong, we were actually going to be working on some additional features of HTML5 we had not yet covered, more specifically geo-location. I had no idea such functionality existed, for all I knew the only way to get a location from a visitor would be to look-up the user's IP in IP2Country database to figure out where the user might be located. From my experience with projects which had this implemented, it was not very accurate for one the IP2Country database (which is huge) would need to be updated frequently, you would also end up with a lot of inaccurate translations. People behind proxies would show up from the country where the proxy they used is located and not the actual location.

With HTML5 the browser will try and make use of the most accurate way of determining a user's location, on testing it out from my home PC, it didn't look too good, while it managed to figure out that i'm in Malta it flagged my location as somewhere in the center of Malta, some miles away from my actual location.

The browser will actually ask you before divulging your physical location, a privacy feature for all those who are worried that the entire world it out to get them.

On allowing the geo-location API to work, I was flagged as being located at Birkirkara, a couple miles away from my actual location, most probably that's where my ISP's servers are located and after the browser exhausted all possible ways of determining my location through GPS, triangulation etc.. it reverted back to the old-school IP lookup, which although not that accurate is far more efficient then maintaining an IP2Location database. On a side note, the location is only available to the client for the server to actually get a hold of your location the client would need to forward the location to the server through an HTTP request such as an AJAX call. 

The following test was carried out during this same session, this time using an iPhone, which comes equipped with GPS, etc... The accuracy here was mind boggling if reported my location to within meters away from our classroom at Pembroke.

Again the browser prompts for a confirmation on allowing the browser to provide your location and on pressing the Ok button, the API is available to that page.

As you can see from the above image here the location service is so accurate it would terrify anyone paranoid about the Internet, but for me the more APIs I as a developer have available the more functionality I can provide to the end user. 

The source for the web page listed above can be found at http://drunktext.org/Daniel.html

PS: It has been recently reported that one of the largest smart phone manufacturers has been tracking the where-about of all it's customers for years, all of which had no idea on what was going on and never pressed any "allow" button anyway.    

   

HTML5

When it comes the the world wide web, HTML5 seems to be the obvious way forward, we have been hearing about it for years and although all mainstream browsers support it to various extents it is still under development and it will likely be years until its specifications are agreed upon and finalized as a standard.

HTML5 is the fifth revision of the HTML standard where not only are web-designers and developers are allowed to resume working on all previous functionality offered through HTML4 but also natively include standard APIs which when thinking back should have been implemented decades ago.

A case in point is video streaming, for the past decade we have all been viewing online streamed videos mainly on youtube through Flash, this makes no technical sense, flash was intended for embed-able interactive animations, was then creatively used to create online games which finally lead to video streaming. The only reason all the big companies started streaming videos through Flash was because there was no other option, a huge percentage of the internet population had flash installed and therefor was their only option. With HTML5 gone are the days of using proprietary software, downloading and installing plugins only to view mediocre video quality. The <video> tag is all you need, and it is already bundled up with most mainstream browsers.

Another case in point is storage, for as long as I can remember us developers had to make due with cookies to provide our users with a feeling of "stateful-ness" over a stateless protocol where every page flowed smoothly to the next page as if they're using a simple application. Because of the limitations available when using cookies (KBs) we would bounce off a unique session id in a cookie with each request to the server for the server to know who the request is coming from and in what state the client (browser) is. Not only is this very insecure, the entire state for each client has to be maintained on the server. With HTML5 the browser has access to various MBs of storage for each domain name (depends on browser) which not only can be used to store client state but also allow for temporary offline availability to the application. Not only does this allow development for much smother applications it also shifts the state from the server down to the client effectively shifting some of the load which should have never have been on the server back down to the client. This results in fewer HTTP requests to the server allowing the server to serve more clients on the same hardware. A win-win situation.

Some obviously missing APIs have also been included, we have all seen tons of java-script code to add drag-and-drop functionality to a web application, which although one can find some good implementations such as the jQuery framework the overhead involved for such a nowadays common way of interacting with a computer. HTML5 provides an API just for drag-and-drop operations allowing for less javascript and more browser compatibility.

Speaking about compatibility, we were all introduced to a neat little site which will rate your current browser from 0 to 400 depending on how much of HTML5 is already supported. Chrome 12 ranked 314

Whilst my iPhone's safari browser ranked 217 which is not bad for a mobile browser.

Some other widely spoken about HTML5 APIs include

• Canvas - allowing for 2d drawing
• Cross Document Messaging - allowing for messaging between different open pages
• Microdata - enhancing the contents on the page to aid search engines and crawlers to easily parse and index the pages.

I'm sure there are hundreds of other interesting features and APIs offered by HTML5 and if I had to list them all this blog post will run into tens of thousands of words and I would never be able to push the "PUBLISH POST" just below the blogger editor ;)

Second Life - Scripting (LSL)

During our previous session we focused on constructing virtual objects by linking multiple prims to form a single object but there's more to SecondLife objects than just creating static objects that do nothing but let Avatars sit on them. We can add interactivity to any object by embedding LSL (Linden Script Language) scripts in our objects. This post will focus on demonstrating some of the functionality available through this scripting language.

LSL syntax is very similar to javascript, but unlike javascript LSL is a strongly typed language requiring all variables to be declared to be of a specific data type prior to using.

To embed LSL to an object, open the build tool, navigate to the contents tab and create a new script.

I have listed a couple simple LSL scripts below to demonstrate the language in action.

Hello, World example

Keeping with the tradition, the following example script will output Hello, World whenever someone touches it's corresponding object.

The llsay() function accepts two parameters, an integer channel and the text, channel 0 is public anyone within the transmitting radius will see the message in their chat area. Other private channels are often used to enable communication between objects. If you want to pass messages from one object to another you can send commands on a private channel where the other object is listening on. The llsay function will transmit messages to a 20m radius around the object.

On clicking the object "touch" the following message will be displayed in the chat area

Sending an Email
The llEmail() function accepts 3 string parameters, destination email address, email title and test message.

The email below was delivered within seconds of clicking the object, the email not only contains the message passed in as a parameter but also additional details about the object such as location.

This function is often used by in-world robots which are interfacing with external system (not on SL) reporting back in-world activities. 

Move object
The llsetpos() function will change the position of the object to that defined by the vector passed as a parameter.

On clicking the corresponding object the object will move 1 meter upwards.

Conclusion

LSL scripting is very similar to nowadays's languages so syntax wise there is no learning curve, the only thing that one would need is some understanding of functions available all of which are documented at lslwiki.net. 

Second Life - Constructing the World

One of the most innovative characteristic on SecondLife is that everything you see in-world has been created by the SecondLife population itself and not the parent company Linden Labs. They simply provide Sims (Simulations) which are actually dedicated server hosting a portion of the map and an array of tools to enable users to created all the content. Everything from house, furniture, vehicles, clothing and even the Avatar's own skin can be created through the SecondLife viewer.

This session was dedicated to the creation of useful objects which can be used for e.g. as furniture. We all teleported to an area called FERMI which is basically a sandbox where all users are allowed to create objects freely.

In SecondLife everything is made up of one or more prims (primitives), even the avatar itself is set of prims together to form a human structure, a prim is just a basic 3D shape such as cube, cone or cylinder. Prims can then be linked together to form more complex structure e.g. the chair below.

The following chair is made up of 4 cylinders (legs and back), and 2 cubes (seat and back), the less prims you use in your object the faster it loads, so if something can be constructed from a single prim do not split it up. e.g. in the image below I could have created the 4 legs as separate prims from the back, but instead I extended the hind legs to form a part of the back. Sims also have a limitation of a couple thousand prims they will allow in that area.

On completion of the structure, just select all objects and link the objects together using the build tool, from that point onward that object will be considered as one.

Any object may be fully customised, for.e.g in the image below I have changed the wood grain texture of the chair to a darker one. (this can all be done through the build tool) 

 All objects in SecondLife have a Sit Here option on right click, this will make your Avatar sit on whatever is selected.

The below image shows my avatar sitting on my newly created chair, luckily the chair's seat orientation was correct on the initial try, buy if the avatar would have sat down facing backwards or some other way all that would need to be done is to rotate the seat to face the correct way (all prims have a pointing direction).

Conclusion
Creating objects in SecondLife was more entertaining than I had initially expected, it only took me a couple of minutes to get to grips with the UI and completed the above structure in less than an hour, granted most of the time was spent on trying to control the camera to get it to show me what I wanted to see and not on the constructing itself. So far the best approach I've found is to roughly align the prims using the on-screen drag-drop functionality and then fine tune each prim's size and position using the parameters in the build tool.

An Introduction to SecondLife

During the next couple of weeks we will be experimenting with Second Life, a 3D virtual world developed by Linden Labs where people (in-world they are called Avatars) can fly, teleport, never die and everything you can see has been built (and programmed) by its inhabitants.

Apart from analysing this technology as "new" social medium, will will mainly be involved with the creative side of the technology from creating in-world 3D objects to embedding LSL (Linden Scripting Language) code to add to the interactivity of these objects, but first let's start with the basics.

This virtual world can be accessed through various client applications known as SecondLife viewers, the official SecondLife viewer supplied by Linden Labs can be downloaded from http://secondlife.com/support/downloads/.  Installation is easy and straight forward just like any other installer. On loading the viewer you are immediately asked for your SecondLife credentials, I found it much better to use the Advanced Mode on this viewer as the Basic interface lacks various GUI functions which might not be that much of a problem for a seasoned user who'd know all the keyboard shortcuts.

On logging in you are automatically "spawned" at a welcome island, which is intended to help users familiarise themselves with the environment before teleporting themselves to the "real" world. On leaving this area there is no way of returning back, which is not really a problem as I didn't see anything worth seeing or doing in this area (Just a bunch of lost souls like me looking for the fly or run buttons).

Navigating in SecondLife is not that difficult but it takes some time to get used it, it will most probably be easier for those who are used to 3D games. In general you have 3 modes in which you can navigate from point A to point B.

1.Walking - agreeable this is the most realistic way of traveling in SecondLife but not the most entertaining, to walk you can either use the WASD or the arrow keys on the keyboard, you also have an option to run.

2. Flying - flying is much easier and faster, you can toggle the fly mode with the F key, which will levitate you a couple meters in the air where you are still able to navigated using the WASD or arrow keys but much much faster.

3. Teleporting - This is the most common and efficient way of traveling in SecondLife, teleporting enables you to hop from one place to another instantly, you can either teleport yourself to various locations using the search feature, using bookmarks you set yourself of be invited by someone else which will offer you a teleport to where the other avatar is located.

An interesting place I came across while trying out SecondLife

Olds AFB, Undine State

Click to visit - http://slurl.com/secondlife/Undine%20State/85/156/25

This area allows anyone to fly any of the dozens available military fighter jets for free, all you have to do is attach a HUD object and you're ready to fly. 

Conclusion

Looking at this project from a technical standpoint I find it fascinating how this company managed to implement all these various technologies across distributed networks to allow such seamless interaction between the avatar and the virtual environment, yet so far I already feel that there's something missing. I also think the 3D rendering does not do it any justice, if for a non-gamer like me (who's impressed with the lightest animation) it looks like something from a couple years ago then what would a gamer say?  

Web Space Management System - Conclusion - Part 4

This is part 4, the final post in the Web Space Management System blog series, as already explained in the previous post this final post will focus mainly on styling the application as all functionality is already in place.

Styling the layouts proved to be very straight forward, originally when planning the post sequences I envisioned this to be a substantial portion of the work but in reality I managed to style all pages within a couple of pages with one css file and some very minor changes to the html element within the output functions to provide adequate identifiers for css.

The image below shows the final index.php page which displays the Create and Login forms

main login/registration page

The image below shows the members.php page which has improved greatly from that shown in the previous posts. In this final version one can easily differentiate between files and folders as now a clear icon is displayed next to each. The Delete link has also been replaced with the delete icon.

members area page

Conclusion
I must say that I enjoyed working on this project greatly, I'm also pleased to now have a deeper understanding of a language that is widely used all over the internet. One will come across mixed reviews when reading about php, people seem to either love it or hate it, there's no in between. Most reasons why people dislike php are unfounded, the most common mentioned reason is that php is not statically typed. This might have been an issue a decade ago but with today's auto-complete features in our IDEs I can't remember when I last typed a full variable or function name. Another commonly mentioned issue is that php code is untidy. In my opinion this has very little to do with the language and more to do with bad practice. I think that php has achieved this outstanding popularity because it's a stable and light weight, does not require cutting edge hardware to run satisfactorily. I'm looking forward to my next project with php.

Web Space Management System - File Management - Part 3

This is part 3 of the Web Space Management System blog series, in this blog post I will be covering the remaining functionality for the application to be complete.

The first thing I did with this version is to copy all the code created in the first blog post in this series Web Space Management System - File Upload - Part 1 and modified the destination folder slightly first to have it located at a higher directory structure than the /htdocs folder thus making in unavailable for users through direct URL requests but also to build the path dynamically in the following format:

<USER_ROOT> / $_SESSION['username'] / <current user directory>

• The USER_ROOT value is a hard coded parameter within the application which defines the directory on the server into which user directories are created.
• the $_SESSION['username'] contains the actual username of the logged user
• The <current user directory> value is actually stored on the session in $_SESSION['currPath'] and defines in what relative directory the user is currently in, to change directories we just alter this value and redirect back to the members.php page.

This structure allows requests for all file system operation to be relative to the user home~ directory and therefore prevents users from having access to other users or system directories.

Functionality included in this version:-

1. Creation of user home directories during registration
As mentioned in the previous blog post Web Space Management System - User Authentication - Part 2 the registration function had to be altered slightly to now create a home directory for each user as part of the registration process. The mkdir() function is used to create directories in php.

2. Directory listing/File system navigation
The members area has now been enhanced with file system navigation functionality, where the user can navigate through his assigned space in an "explorer" like fashion. both directories and files are click-able, clicking a directory navigates the user to that directory whilst a file will be downloaded once clicked.

The section highlighted in greed specifies the directory listing interface

The directory listing is achieved using the readdir() function, although not very clear in the current implementation I am already verifying whether a the listed element is a file or a directory using the is_dir() function to determine what action should be taken when the user clicks the filename - download or navigate, this same property can easily be used later when styling the layout to display a folder icon next to directories.

3. New folder creation

Apart from their home directory users are also allowed to create new folders within their area, a folder is always created as a child of the current directory the user is in.

The section highlighted in red specifies the folder creation interface

The create folder form posts to the createDirectory.php which will create a directory in the user's current path <USER_ROOT> / $_SESSION['username'] / <current user directory> using the mkdir() function

and then refreshes back to the member.php page which will give the user the illusion of an instant directory creation.

4. File download

As it is clearly shown in the above images, all files listed on screen are click-able (hyperlinks), all files redirect to download.php?f=<user relative path/filename>. Since the files cannot be accessed directly through a URL request (as they reside at a lower directory level then /htdocs) php will read the selected file and builds an http response with the contents of the file. Apart from added security for the user's content this also prevents the user from executing any script on the server such as php script as none of the downloads are routed through the interpreter but are served as is. Folders are also click-able but these requests are forwarded to the goto.php script which will reset the $_SESSION['currPath] to the selected path to allow the users to navigate though their content. 

5. File/Directory deletions

Any files/directories residing in the user's domain can be freely deleted by the user by simply clicking on the delete link available next to each list item. All deletions are routed through to the delete.php script which will check whether the $_GET['f'] - for file deletions or $_GET['d'] - for directory deletions have been set. Files are deleted using the unlink() function while directories are deleted using the rmdir() function.

In the next blog post, I will be going though the styling processes involved in converting this fully functional application to something more presentable.

References:
Calculate directory size using PHP - http://www.go4expert.com/forums/showthread.php?t=290

Web Space Management System - User Authentication - Part 2

Welcome to part 2 in the Web Space Management System blog series, this post will mainly focus on the security aspect of the application by enabling registration and authentication functionality.

The current project is structured as follows.

I  kept the folder structure as consistent as possible with the previous blog posts but also sufficiently organised as otherwise it would have been a nightmare to maintain. The root directory only contains pages which will be requested by the user directly or scripts which will directly process user input, everything else goes into nested directories in the includes folder. Users can then be prevented from accessing the /includes directory by simply configuring an .htaccess file in that same directory.

The first page the user will load is the index.php page which gets served by default by apache when a file name is not specified. This page will check if a user is logged in by checking the $_SESSION variable for content and if found redirects the user directly to the members.php page, otherwise the user is presented with 2 forms, a registration form and a login form.

All output* functions are loaded from the includes/output/* directory and simply echo out various sections of html, 1 output function per file will be used, mainly to keep the the project as atomic as possible with less impact should any changes be required at a later stage.

The outputNotLoggedInPage(); which should return the main body whenever a use is not logged in calls various other output functions e.g. outputRegisterForm() which renders the registration form and outputLoginForm() which renders the login form. In this manner the final page presented to the user will be made up of multiple sections defined as by the respective output functions.

The following page is displayed whenever a visitor (not logged in) requests the page, the individual sections that make up the entire layout are marked in color.

Please not that, none of the layouts presented in this blog post have been styled as this will be done at a later stage when all functionality is implemented and tested.

Both the registration and the login form use the post method form submission and are processed by processLogin.php and register.php respectively which will post back to the index.php page with any outcome in either the $_SESSION['error'] and $_SESSION['message'] variables depending if successful or not.

The index.php script will check if any of the above variables are set and if so will echo the results back to the user and then unset the variables to prevent the messages from being shown multiple times. Both message types could have been easily stored in a single session variable such as just $_SESSION['message'], I chose to keep them separate because I might need to differentiate between successful and error messages when styling the pages.

User Registration

The user registration feature will allow any visitor to create an account on the system, all user details will be stored on a MySQL database in a user table which is currently structured as follows.

The password field is a 32 character long field as passwords will not be stored in plain text, but as an md5 hash of the seeded password.

On submitting the registration form the control is passed to register.php script which will process the registration by first validating that both fields were populated correctly and then verifies that the inputted user is not already used, if all validation checks are passed all user inputs are escaped through the mysq_real_escape_string() function to protect against SQL injection attacks. The password input is concatenated to the SEED constant and then hashed using the standard md5() function, in this manner we are not storing passwords as plain text on the database, a seed is used to make it harder for successful dictionary attacks on the md5() hashed passwords should this data ever be compromised. A new record is created in the user table, and the apropriate messages are displayed to the user using the $_SESSION['error'] and $_SESSION['message'] as explained earlier. The registration process will be slightly enhanced later to create the ~home directory for each user which will contain all user uploaded files.

account registration - form filled in

account registration successful

User Authentication

On submitting the login form the control is passed to the processLogin.php script which will call the login(); function to authenticate the user, again all user input is escaped through the mysql_real_escape_string() function. The inputed password is then re-seeded (password concatenated with the same SEED used during the registration process) and hashed to be compared to what is on the database. On a successful login the user is redirected to the members.php page. Once authenticated the user will be automatically redirected to this page even when requesting the index.php page.

login form - filled in

successful login - user redirected to the members area

Logout Feature

The session needs to be destroyed whenever the user requests to be logged out, a generic action.php file will be used to handle such requests, the logout link displayed in the members area is a hyper link to action.php?a=logout which will simply destroy the session and redirect the user back to the index.php page.


Conclusion
in the next post I will do some modifications to the register feature to create a ~home directory for each user as well as integrate the file upload functionality developed in the first post of the series.

Web Space Management System - File Upload - Part 1

This blog post will be the first part of a series of blog posts through which I will share my experience while working on the course work for my second semester – a web space management system.

I will be splitting up the course work into the following parts

• User authentication – User registration and login functionality
• File upload – File upload functionality
• File management – create/delete directories, move/delete files.

This first post will focus on the file upload functionality; we will only be working on 2 files, the index.html which will contain the file input form where the user selects the files to upload and the uploadFile.php which contains the backend PHP code to handle the actual file upload.

Index.html

 The index page contains a simple html form as used in the previous blog post. Since the form will be handling files the enctpye attribute has been set to multipart/form-data and the input field type attribute has been set to file, this will allow the user to select files located on the local machine to be uploaded. The above script will post the form to the uploadFile.php page.

On chrome the above html page will be rendered as follows

 When the user clicks the choose file button an explorer window is opened for selection.

uploadFile.php

 This script takes care of the file upload process, it moved the uploaded file to the uploads/ directory and prompts the user when successful

The example above simple demonstrates the functionality that PHP offers to handle file uploads and although it works should not be used without further validations and restrictions.

Some vulnerability with this setup

• Full directory listing of the upload directory is available to everyone navigating to http://localhost/phpFileUpload/uploads/

•  Users can execute PHP code on the server by uploading .php files and loading them from the browser as explained below.

1. Upload hack.php file containing the following text <?php echo "PHP code executed on server... " ?>
2. Load http://localhost/phpFileUpload/uploads/hack.php

As you can se from the above screenshot, the PHP code was executed.

In the next blog post I will go though the authentication system as well as how to secure the application against malicious attacks such as the one shown above.

PHP & MySQL - Simple Guestbook

Now that we have our environment set up and ready to go, I decided it would be a good time to start experimenting with PHP, but before we go any further let's first stick to the hello, world tradition.


<?php
echo "hello, world";
?>


Ok now that the "hello, world" example is done let's start working on the real task at hand i.e. a PHP/MySQL powered guestbook.

The entire project is made up of the following 5 files.

I will go through each of the above files throughout this post.

index.php

Index.php is the main page and is the only page the user will interact with, it lists all existing guestbook entries as well as provide the user with a form to input additional entries.

Although this entire PHP application could have easily been implemented in just a single index.php file, it is considered bad practice to mix page markup with PHP code, I have therefore segregated all PHP code to separate files residing in the /include directory each of which is called whenever required using the include() or include_once() function, it is important to use the include_once() function on files which should only be executed once e.g. the MySQL connection include file, you only need the connection to be established once.

PHP includes

Line 9 - inc_mysql_conn.php is included, this assigns a database connection to the $db_conn variable which would then be available throughout the script.

Line 10 - submit_entry.php is included, this script is triggered only when the submit button is pressed and after validating the entry will insert the entry into the database.

Line 14 - list_all_entries.php is included, this script outputs all entries in the guestbook to the browser in an HTML table.

I will go through the PHP code on each of the above included files later in the post.

Input Form

The above html form submits data back to the index.php page using the post method (line 18), although for this application the get method would have been fine, I usually prefer using post over get just to keep the URL clear from any query string clutter.

There are 3 visible text fields, name, email and comment and one hidden field. Since the form is posting to itself the hidden field will be used later by submit_entry.php which will read it's value to check whether the submit button has been pressed and therefore data needs to be inserted in the database.


inc_mysql_conn.php

This php file opens a mySQL connection with the database which can later be used in any part of the application.

This script opens a connection to a MySQL server logging in with the credentials defined in the par_db.php script. Once this script is included it makes the $db_conn connection available throughout the execution which is the main reason why this is usually one of the first included script in any project. It is considered good practice to unset any variables which are no longer required.

par_db.php

This php file is used to define the mySQL connection parameters, the primary reason why this data is contained within a separate file is simply to prevent modifying files which contains functional logic whenever these parameters need to be altered.

The above script simply defines the credentials used to login to the MySQL database.

list_all_entries.php

This code will output all guestbook entries in an HTML table, this page

This script will retrieve all guest book entries from the database and iterates through each record to output an HTML table to the browser, this script is included whenever the guestbook entries are to be listed.

submit_entry.php

The above script is responsible for validating and inserting guest book entries into the database. It first checks if the form has been submitted or not, since we are posting to the same page we would only want to execute the insert statement when the submit button has actually been pressed, the most common way of doing this is by placing a hidden field on the form and then checking if the variable has been set or not using the isset() function.

I am then validating the inputs to verify that all fields have been populated and when valid inserting the values into the database by executing an insert statement.

The above code is considered safe against SQL injection attacks, as all user inputs are passed through the mysql_real_escape_string() function which escapes special characters, it is still vulnerable to other injection attacks such as cross site scripting.


Seeing it in action

The first time the page is loaded the user is only presented with the input form.

The user is now able to input guestbook entries simply by populating all fields and pressing the submit button. The data is validated prior to being inserted in the database and as you can see below, the submission was rejected because both the email address and comments field were left blank.

In the example below, all fields where populated and the comment was inserted in the database, "Comment added..." success message and the actual comment are immediately shown on screen as the form submits to itself so no refresh is required.

The below screenshot shows how multiple comments would be displayed.

I have attached all sources mentioned above in the attachment below for anyone interested.

PHPsimpleGuestBook.rar

Setting up the Environment

For this semester we will mainly be focusing on the server side scripting language PHP. This blog post will go through the entire process of setting up everything that is required before we can start hacking into the PHP language itself.

Setting up XAMP

Up until a couple years ago, if you wanted to configure a local development environment where you can deploy and test PHP applications, you would have to spend hours reading through contradicting documentation from various vendors to install and get Apache, PHP and mySQL to work.

Fortunately, that is now a thing of the part thanks to XAMPP. XAMPP is a pre-configured packaged solution which primarily contains the Apache web-server, the mySQL database server and the PHP interpreter. After XAMPP has been fully installed all services can by controlled from the XAMPP control panel.

Common issues when trying to start Apache

The most common reason why Apache may fail to start is that some other program is already listening on port 80 or 443 which are the default http/https ports.

To check what program is listening on these ports type the following command in cmd.

netstat -o -n -a | findstr 0.0:80 and netstat -o -n -a | findstr 0.0:443

If any of these commands return anything it means that those ports are already in use. The last number in the returned string is the pid (process id) and you can see what process it listening on that port by using the following command

Tasklist | findstr <pid>

As you can se from the above screenshot, VisualSVNServer.exe is already listening on port 443; you can either stop the process and retry starting apache or chose another port for apache.

SSH listen port can be configured from the following file xampp\apache\conf\extrahttpd-ssl.conf to 444 (after verifying that that port is currently not used)

Experimenting with XAMPP

Loading the main XAMPP page

By default the homepage on the installed apache server is the XAMP web interface, it provides the user with various tools vital to ensuring that the installation has been set-up properly and that the various services are running as expected.

Status Report

This page displays the same information as the desktop Control Panel, it shows the status of the various services installed through XAMPP.

In the above screenshot all services except Tomcat are activated.

Security Report

This report performs various security checks on the various services running through XAMPP, the below screenshot shows the security report for a freshly installed un-secured setup, the various checks also include details as to how to rectify the security issues. For e.g. changing the default ftp password.

phpinfo()

By seeing this page one can be sure that PHP has been installed and correctly loaded by the web server, this page lists the full details about the current PHP installation configuration as well as all modules/libraries loaded. This is usually the first place to look when certain functionality within an application is not working as expected on a server. This page can be easily generated from a simple PHP file by calling the phpinfo(); function directly.

Phone Book sample application

This sample application shows some simple PHP in action, it allows the user to create/remove entries from the phone book.

FTP Access

I used the winSCP ftp client to log in to the ftp server by setting the host to localhost, port to 21 (the port the ftp server was configured to listen on) with user 'newuser'.

Upon logging in, I had access to the ftp directory where I could create, edit and even upload files to the server, I created a test file in this directory to verify I had write access.

XAMPP also provides a shortcut to the FileZilla Server terminal (Available by clicking the admin button in the XAMPP control panel). The terminal outputs all activity going through the server as well as lists users currently connected to the ftp server.

This terminal also provides the admin with all functionality required to maintain the server, such as user account maintenance and directory permissions.