Drift Into View 5: Throw The Switch

Sunday, 16 January 2005

After spending so much time working on Electron Drift on my local hard drive, the time had come to upload it to my web host's server and see it work for real. The end of the road. The last stop. The final destination. The story climax. Or... perhaps not.

Effendi, I am not deceived that easily. I have foiled your simple but cunning plan. Who would believe that it would work out just fine and there would be no problems after going live?

I Never Promised You A Rose Garden

Recall that I could not test my SQL properly. In 2004, stored procedures had only just been added to the latest version of MySQL which meant all of my SQL had to buried inside the PHP code. It was not possible to test the SQL independently on the production web server, refine it and bring it home again. It could be argued that the SQL calls could have been isolated in a small PHP library. In fact, that is exactly what I did, and I do have a PHP library charged with interacting with the database. However, I could not seriously test my SQL independently from my "first baby steps" in PHP and concluded that it would probably not be worth the extra effort.

Also recall that my "development" system, my home PC, was completely different from the "production" system, my web host. I found that many of my queries just didn't work on the production system. I started to worry that the seemingly crude MySQL syntax (on version 3.2.3) would be unable to deliver on some of the queries I wanted to implement. However, I was able to get around all of the SQL problems eventually.

Finally, as I hinted in the previous article, my big push to finish off the web project before I left Japan resulted in dumping error handling. Naturally, on any other project I would have taken the time to implement elegant exception handling, particularly as I believe that the hardest part in any code is building appropriate reactions to bad situations. Since this was a personal project, though, I was quite happy to deal with unreadable PHP error messages jumping out at me on the screen. It did, sadly, increase the amount of time getting to the bottom of each problem, because none of the errors were being trapped. (Just think of Visual Basic's crime against nature called "On Error Resume Next" and you'll get the picture.)

There were some other minor issues that were not related to the go-live, but went unnoticed during my test period. For example, the HTML did not validate. This was actually a result of one of my many skirmishes with CSS and it always takes me a while to get the CSS elements right. In fact, I found another problem with the CSS on the web site just last month (but only under Internet Explorer, fantastic).

I also had a problem with entities being lost when displaying them in the edit form. For example, if I had &amp;&lt; typed into the form, when it was retrieved again later, it would naturally appear as &<. On the form, however, I need them to appear as they did originally, because that is what I typed originally. An extra bit of PHP code was all that was necessary to protect the entities in the form.

So, was that it?

Security, Security, Security

I am absolutely paranoid about system security, mainly because I know so little about it, but also because there are just so many potential pitfalls. To an aspiring web developer, security seems to be encouraged as an afterthought, rather than a method by which a site is constructed. Discovering the default configuration of MySQL was insecure only reinforced my views.

I was particularly uncomfortable with putting database parameters inside PHP files, it just didn't feel right as these files are not hidden; the web server is meant to strip out the offending PHP code before the files are transmitted to a web client. To help ease my mind a little, my PHP code libraries were moved into a subdirectory of the main site and (Apache) indexing was switched off on the directory. This means that a virtual directory listing is not available to a web client making it harder to find "hidden" files. Not perfect, but an improvement.

There was another problem, also related to security. Amongst the functions available to the site administrator (a.k.a. "me") are two options which involve file system writes: regeneration of the RSS feed and media file upload (images etc.). They worked like a charm when I tested these functions on my local PC but when executed on the web server... I was faced with a white browser window bearing a PHP error. The code could not write to the local file system.

I got in contact with the support people at my web host and they said the PHP module on the web server was not set up with suEXEC. My immediate reaction was: what the hell is suEXEC?

Well, you see, the PHP scripts run as the web server user - a user known as "nobody" - and this user does not have write access. I could set the relevant file and directory permissions to 777, but who wants to grant write access to the world? This is where suEXEC comes in: it allows the web server to run scripts as a different user.

My web host kindly moved my account to another server which had PHP set up with suEXEC. I was told that on the server, my scripts would run as my user instead. I thought this would solve the problem; after all, I can read and write to the directories using FTP.

I remember it got to 3am and I received a mail indicating that the account had been copied to the new web server. I decided to give it a test, using the raw IP address because the domain name was pointing to the old server. I had hoped to see the scripts run without any special intervention on my part.

No dice. Same error message.

Those waiting for a neat conclusion to this story will be surprised. At 4am, after I had sent a question to the web host support asking what was going on, the web host told me that I would still need to add write permissions to the world to ensure that the file could be written to. I was pretty tired. I was wondering why, if I still had to open up the permissions, I had bothered to get the account moved across onto a different server. Uh, right.

There's a message here, but I'm damned if I can puzzle it out.

I gave up. Before writing this article, I spent some time sorting through web articles on PHP permissions and user authentication, as well as reviewing the heavy, physical books I have resting on my lap, gently destroying any chance I might have of children in future. I came to no conclusions about what I was supposed to do in this situation. When you're not in direct control of the web server, your options are limited. A lot of the articles online make an assumption that you installed the PHP module, you maintain the Apache server and you own the Linux box it all runs on.

Life's too short to keep fighting miserable, pointless battles like this, so let's move on. There's a lesson to be learned, but it's not about security. I'll come back to that at the end.

But that was it; Electron Drift was finally live.

Feelings

Not to put too fine a point on it, I am very comfortable with the design of Electron Drift. It does not really offer much beyond conveying content to the user. No adverts, no massive list of links drowning what you're trying to read. XHTML 1.0 compliance. CSS that works and isn't too complicated. A page that responds fairly well to browser window and font resizing. Gentle colour scheme. The web site is dynamic and updated online. Backing up is accomplished by using phpMyAdmin on the web server to dump the database from time to time.

Internally, I have a few complaints. I would like to have error handling. I would also like to have a slightly smarter management of media files. Finally, the structure of the PHP code could have been better implemented, but this is no surprise considering this site was part-experiment.

There are, however, two questions I might ask myself, especially as no-one else will.

Why no forum or comments facility? Firstly, they are non-essential features which certainly don't need to make it in to the first release. Secondly, I feel comment facilities on a small site like this may simply be an attention-seeking exercise. I'd rather not publish my personal psychological makeup on the web, not on our first date. Thirdly, what could be more depressing and sad than a web site with a comment facility that doesn't get used? Ever?

Why is there no latest article index on the front page? After all, I learnt a long time ago that having the latest articles listed on the front page is a good thing as opposed to some hierarchical structure where you can't find the newest content. The truth is that the front page of Electron Drift is a bit of an experiment. I thought that perhaps it might be more considerate to give visitors the newest content straight off the bat, especially in view of the infrequency of the updates.

I am still debating the pros and cons. It may be a little jarring to suddenly find yourself knee-deep in content if you've never been to the site before. Plus, if you want to send the link of the latest article onto someone else, surprise surprise, more often than not you'll be forwarding the link of the front page which will give you a different article in a few weeks! For these reasons, I may decide to add a more classic front page in future.

But for now, I consider Electron Drift to be complete and maintenance-free.

Moral Of The Story

I do not write these articles trying to cast myself as some sort of international superguru, there are plenty of those around already; I write about personal experiments and thoughts. The solution to the ills that plague software development are not to be found here (and believe me, there are some ills). I wanted to redevelop this web site to learn about web site programming and, of course, I have barely scratched the surface. Where's the shopping cart and credit card database? Where's the ability for a user to customise their experience? Where's my focus group and sales team? Despite the lack of riches that it was once thought the web would bring (Step 3: Profit!) I am happy with the exercise. It dragged painfully at certain points, but much was learnt.

You learn more when you fall than when you succeed. The major problem with the Electron Drift project was using a production system that was completely dissimilar to the development system, which was only partially out of my hands in this project. I was unable to control what was implemented on my web host's servers, but I could have at least got the PHP and MySQL versions on my PC to match. Installing Apache locally could have further reduced the gap between the two environments, as well as taking IIS out of the equation; I would have been even happier to have had a Linux system on standby to play with, but I would have needed a second PC for that to have been effective. For a serious project I would maintain the production environment as well; although this would cost both time and money, it would reap rewards later in terms of complete control and the peace of mind that releases would not bring down the production site.

I also have a better understanding of web site development structure. A web site is a collection of pages, not necessarily a program or module with defined access points. Ignoring that will likely produce a body of web code that has a rough texture to it; it will work, but it won't feel right.

However, I am still concerned about security aspects. If I was going to implement a commercial site I would have to do some homework to be completely comfortable that I hadn't left the back door slightly ajar. Security concerns are scattered in nature and thus dealt with on a case-by-case basis. For example, installation of software, such as MySQL, requires awareness of how to configure it to be secure. Then there are SQL injection attacks which are fixed by handling user input correctly. Don't forget that you've got to keep patching your system too...

[Update 17 Jan 2005: A helpful security link just turned up today.]

Sure, I would love to convert Home to a PHP/MySQL web site but that would be a much larger project, particularly as I would need to work out how to port the existing articles into the new site. Home is fine as it is right now, I have no intention of goofing around with it.

Anyway, time well spent. I never underestimate the time required to tackle an unfamiliar technology, so I am quite pleased that I broke the back of two technologies - PHP and MySQL - and briefly tampered with IIS. I also managed to push my CSS understanding forward.

I now feel that more than enough time has been spent in the web arena and I want to try my hand at something completely different. And I'm sure you'll be pleased there'll be no more of these damn Drift Into View articles.

End