About a month ago I wrote a post on how to protect your forms from double posting and CSRF attacks using nonce words in CodeIgniter. I realized pretty soon though that the code I posted wasn’t as smooth or, in fact, as functional as it should be. So to save my own ass I though I should share this update with you guys.

I would like to put this in a less shameful way, but the fact is the library didn’t do what it was supposed to do. On every page refresh a new nonce was created, which indeed hindered an attempt to simply press the back button and resubmit. Problem was that if you submitted yet another time after the error message about the invalid nonce (well, you probably should word it differently to the end user) was displayed, the nonce passed validation.

UPDATE: A new and improved version of this extension can be found in my post Form protection revisited!

In a web application for record collectors I wrote a few years ago I recently had to deal with users who added the same record hundreds of times. I did use the PRG, or Post/Redirect/Get, pattern which means that you always redirect the user after a post request so that a simple reload won’t resubmit the same data. This prevents users from mistakenly resubmitting, but by pressing the back-button the problem re-emerges. The solution is called a nonce.

Date validation usually means regular expressions, and regular expressions usually means headache. All in all, I do think that PHP’s date handling is pretty sweet, but native validation is still lacking. With PHP 5.3 though, we are one step closer thanks to a new function with the infinitely long name date_parse_from_format. I’m going to show you how it can be used to create a validation function for any PHP date format.

I recently finished a project for a client in CodeIgniter where a large part of  the site was made up of static pages. The obvious approach for this is  to create controllers and methods to load these views, meaning that the method team() in controller Football would load the view views/football/team.php and be done with it.

This, no offense, seemed stupid, so I decided to create a fallback controller that would have the sole task of dealing with unmatched requests. In other words, if the current URL can’t be matched to a controller method,  the request will be dispatched to the specified controller. In the example of the client site, this would then load the view who’s folder structure and filename matched the URL (see Football example above), but it could pretty much be tasked to deal with anything from error logging to paying your taxes.

A disturbance of mine in CodeIgniter is when I want a controller named the same as a model. The standard way of solving this is calling your models for example UsersModel, Users_m, or the likes. This has the unpleasant side effect of making your code look fugly. The other option would be to do the same to the application controllers, but this would affect the URL instead of the code which is probably worse in the end since that would affect the end-user. So what to do?