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.