This book is split into two distinct sections. The first is a very touching, inspiring account of the authors time in concentration camps during WW2. I found his analysis of the different psychological stages they went through really fascinating and the modest prose in which he spoke about his experience was humbling.

The second section is a summary of his philosophy of Logotherapy. Although this raised a number of insightful points, towards the end I realised that as I only have a passing interest in real psychology this section was largely wasted on me. Still, it’s not too hardcore and there’s plenty to take away from it.

So if you’re looking for meaning in your life, give it a read!

However, I ended up settling on DECIMAL which allows you to set the precision (significant digits) and the scale (digits after decimal point) and this seems to work (as far as I’m aware you can also do this with FLOAT too). So for example I defined my field like so:

DECIMAL(4,2)

I can’t remember off the top of my head what the difference is between FLOAT and DECIMAL. I think it’s to do with the way they are stored internally, with DECIMAL working in the way you’d most often expect. Anybody know any different?

Also, found a really amazing video that can be watched here.

Tonight I thought everything was fine, then I did a simple page redirect. On the other side I tried to read from $_SESSION and everything had disappeared. I spent too long pouring through the code before I realised what was wrong.

Apparently PHP / Apache regards “www” as a subdomain. I was redirecting from http://example.com to http://www.example.com so everything got dropped. A simple mistake to make and easily overlooked. When I figured out the problem I found this post on PHP.net.

Strangely I’ve never noticed this behavior before. I wonder if it has always been there or it varies between Apache 1.3 and 2.

I’ve gobbled this book up in just over a day (against the authors advice) and I have to say it’s one of the best books I’ve ever read.

Go. Read. Now.

This is by no means a comprehensive list, but here are some common security issues that I have encountered with some simple fixes.

1. Use mysql_real_escape_string()

SQL injection can be a big problem, but it is easily defeated. Validating every input into your web application is a must, whether it comes from $_POST or $_GET. If it passes this validation then you should wrap mysql_real_escape_string() around the variable to escape dangerous characters. For example:

$query = “SELECT id FROM logins WHERE username=’”.mysql_real_escape_string($_POST['username']).”‘ AND password=’”.mysql_real_escape_string($_POST['password']).”‘”;

2. XSS protection

Cross site scripting is a real danger, but is something that can be protected against without too much work. Simply remove HTML / Javascript tags from any input by using str_replace or an equivalent. I find that I only need to worry about this when dealing with textareas, because text fields are usually a lot more locked down to the type of data that needs to go into them.

3.URL Manipulation

Web applications typically pass information through URLs. Consider the following link:

view_personal_info.php?my_user_id=123

In this example I think we can probably take “my_user_id” to be my id on the system. So what happens when I go to the URL with id 124 or 125? Will I get information on other users? Probably, and that’s why on every page you need to check that the current logged in user has the correct access to view the information.

This isn’t hard to do, so I’m not going to explain the solution here. However, if you’re passing a lot of information through a URL and want to make sure it’s not tampered with, then there’s a straightforward way to achieve this. Creating a hash of the data with a password only the application knows, passing it in the url  and revalidating it on the target page works a treat.

4. Use forms, not links

I’m guilty of having done this once or twice, mainly due to ignorance, but when you’re doing any database modification it should always happen through a form, not a link. Otherwise people can craft links to pages like delete and trick you into clicking on them. If the pages aren’t properly password protected, then it’s also possible that search engines can crawl your site and wreck your database.

5. Other

There are plenty of other little tweaks you can make to your PHP configuration to improve security, depending on what you’re doing and how locked down you want your server to be. Two little things I do when putting code on a live site are turning error messages off, and moving pages that don’t need to be read directly outside of public_html.

I think the hardest thing about PHP and web application security in general is the range of scope for attack. Every input has to be validated, and in a big application this can be easily overlooked. Unfortunately, it only takes one error to bring your entire application down.

The highlight probably had to be Stealth, what a ride! I thought it combined Alton Towers’ Rita with Oblivion. 0 - 80mph in under 2 seconds. Weeeeeeee!

I’ve succeeded in doing this myself before, but I remember the process to be a bit of a nightmare. Yesterday I dropped a line to the support guys at futurehosting.biz and they set it all up for me within 24 hours.

It’s always worth paying a little extra; managed hosting is only more expensive if you don’t value your time. Giving the task to an expert has saved me a night of hell and I’m virtually guarateed it’ll do what it says on the tin!

Kublax grabs all your online bank accounts and gives you a “money overview”, with graphs and charts. It tells you how much of your money is being spent on bills and other things, and lets you setup alerts so you know the status of your bank account. Great customer service too, I emailed them at 7pm on a Sunday night and they got back to be within a few minutes.

I remember discussing a similar idea to this with Shazz about a year ago which never went anywhere, so I’m glad to see someone acting on it. Looks like they have got some pretty cool pipelined features too, so I look forward to trying it again when the product’s a bit more mature.

Now this works fine with Firefox, but I ran into a few problems with IE. It turns out that IE doesn’t support it, but luckily someone has posted an alternative solution here which I thought was rather clever. Here it is again incase the site isn’t available later on.

function getElementsByName_iefix(tag, name) {

var elem = document.getElementsByTagName(tag);
var arr = new Array();
for(i = 0,iarr = 0; i < elem.length; i++) {
att = elem[i].getAttribute(”name”);
if(att == name) {
arr[iarr] = elem[i];
iarr++;
}
}
return arr;
}