MAMP actually comes bundled with Xdebug, though it is not enabled by default. The first thing I did was to upgrade the version of Xdebug to 2.1.0. I don’t think this is required, but it sure didn’t hurt. Just download the PHP Remote Debugging Client from the the boys at ActiveState and replace the xdebug.so in your /Applications/MAMP/bin/php5.3/lib/php/extensions/no-debug-non-zts-20090626 folder (the date on the end might be different, but just go with what you find!) with the one unzipped from the downloaded file.

The next step is to enable Xdebug which we do in the php.ini file. Open up MAMP, select File -> Edit Template -> ‘PHP 5.3.2 php.ini’ from the menu and modify the end of the file so that it looks (somewhat) like the one below. This is just an example however, and these INI-settings are basically a mash-up of all the tips I found while googling the matter. Especially note that the xdebug.default_enable, xdebug.remote_autostart and xdebug.idekey settings are not mentioned in the NetBeans Wiki’s guide, so it might be that they are not required. Also be really sure the Zend Optimizer line is commented out, since it apparently interferes with Xdebug.

[xdebug]
xdebug.default_enable=1
zend_extension="/Applications/MAMP/bin/php5.3/lib/php/extensions/no-debug-non-zts-20090626/xdebug.so"
xdebug.remote_enable=1
xdebug.remote_log="/var/log/xdebug.log"
xdebug.remote_host=localhost
xdebug.remote_handler=dbgp
xdebug.remote_port=9000
xdebug.remote_autostart=1
xdebug.idekey="netbeans-xdebug"

[Zend]
;MAMP_zend_optimizer_MAMP

After this step I wasted a lot of time on trying to find out why NetBeans couldn’t connect to Xdebug. Finally I rebooted my computer and everything was suddenly working. My best guess is that this was due to a conflict on port 9000 (possibly with Skype). Feel free to try it out with only restarting the MAMP server but remember to do a full reboot if things still aren’t working.

By now you should be up and running. NetBeans debugging functionality is pretty straightforward, however you might want to check out the official documentation to get started. Hope this saves someone else a few hours, and feel free to share your tips in the comments!

Happy new year! Over the last six months I’ve become the proud owner of both an iPhone and an iPad. Indeed, the fanboy accusations are getting hard to dismiss. Anyhow, my fiancée also got an iPhone and I thought I should do something useful with that.

I guess most people have heard of the amazing (and free!) Dropbox. In short, it is a file sharing service that integrates directly with your file system. Simply drop a file into the Dropbox folder and – wham! – you can now access it via the web, a mobile application or another computer, or share files with your friends and family. Other applications can utilize this great feature, and one of those is PlainText. It is an iOS text-editing application that syncs all files using Dropbox.

One lacking feature of PlainText though, is that it does not give you the option of sharing files and folders with others, which would be really useful for, say, grocery shopping. I realized it would be pretty sweet if whenever Emelie or I thought of something we needed to get at the store, we just wrote it down in an app and both of us would have instant access to the list, so it wouldn’t matter which one of us went shopping. Since PlainText uses Dropbox, this is in fact a rather simple thing to set up.

First of all I created a new folder in PlainText, since I want easy control over which files to share. This folder will be synced using Dropbox so after it has been created, manually share the folder with whomever you’d like either by right-clicking the folder on your computer or via the web interface. When you share a folder within another folder, the receiving user will have it appear at the lowest level in his or her Dropbox folder structure, so make sure they move the shared folder inside their PlainText folder.

And, voilà! Time to get the freaky co-editing started! If the folder does not show up, or disappears after it’s been shared, do a hard restart of the application on your device. It did the trick for me.

Do you have a nice Dropbox trick? Or simply know of a free app that does this same thing, only ten times better? Share in the comments.

For all this time I have been lazily reading and composing mail, using a few filters to get those incoming messages bagged and tagged but keeping every single e-mail in the inbox. It was only a month or so ago I realized the beauty of the Archive button, which was only sporadically used before. Since then I’ve got a very clear work-flow for dealing with all my mail.

The main goal is to keep your inbox empty. If you haven’t seen an empty inbox since the last trembling months of the last millennium you have no idea what you’re missing. It really gives a feeling of peace to see that nothingness stare back at you – no judgment for not replying, no expectation to be populated, just a blank slate. This is not always possible though, but most of the time I do manage to keep it empty.

Whenever a new e-mail pops in, I read it. Now, that’s not so hard? Once read I decide if I can answer it right at this moment, and if I can, I do. Thereafter I archive the conversation and move on. Archiving obviously also goes for informational messages that does not need any reply. Those e-mails that I expect to be able to answer in the next day or two are allowed to remain read in the inbox. That’s pretty much it!

Now, you may ask yourself “How about e-mails that I won’t be able to give an answer to until a further date?”. The answer to that is for you to reply immediately and write exactly that, and we are magically back to step one. For those really important e-mails that I might need to reference for longer periods of time I like to use the Star feature of Gmail.

Is the clutter-free inbox the way of the future or a pointless Getting Things Done-inspired waste of time? Go for comments.

Image by Jim Epler, released under Creative Commons.

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.

That was the big problem which has been solved, but there’s more! First of all, the nonce now also contains a random element, further lessening the chance of an attacker being able to brute force the nonce word even though a successful attempt would be highly unlikely even before this addition.

Secondly, I’ve made some convenient changes to how to use this extension. The hidden field is now automatically output when you use the form_open function, and if you’d like to do it manually you should be able to figure it out yourself. Also the run method has been extended to mark a nonce as used after successful validation, so you don’t have to do it manually in the controller.

So this is the code you’ll need:

/*
 * Helper (helpers/MY_form_helper.php)
 */
function form_open($action = '', $attributes = '', $hidden = array()) {
    $CI = & get_instance();

    if ($attributes == '') {
        $attributes = 'method="post"';
    }

    $action = ( strpos($action, '://') === FALSE) ? $CI->config->site_url($action) : $action;

    $form = '<form action="' . $action . '"';
    $form .= _attributes_to_string($attributes, TRUE);
    $form .= '>';

    if($CI->form_validation->has_nonce()) {
        $value = set_value('nonce');
        if($value == '')
            $value = $CI->form_validation->create_nonce();
        $hidden['nonce'] = set_value('nonce', $value);
    }

    if (is_array($hidden) && count($hidden) > 0) {
        $form .= form_hidden($hidden);
    }

    return $form;
}

/*
 * Library (libraries/MY_Form_validation.php)
*/
class MY_Form_validation extends CI_Form_Validation {
    private $use_nonce = false;

    function __construct() {
        parent::__construct();
    }

    /**
     * Create a new unique nonce, save it to the current session and return it.
     */
    public function create_nonce() {
        $nonce = md5(rand() . $this->CI->input->ip_address() . microtime());
        $this->CI->session->set_userdata('nonce', $nonce);
        return $nonce;
    }

    public function has_nonce() {
        return $this->use_nonce;
    }

    public function run($group = '') {
        $result = parent::run($group);
        if($result === true) {
            $this->save_nonce();
        }
        return $result;
    }

    /**
     * Mark the nonce sent from the form as already used.
     */
    private function save_nonce() {
        $this->CI->session->set_userdata('old_nonce', $this->set_value('nonce'));
    }

    /**
     * Set form validation rules for the nonce.
     */
    function nonce() {
        $this->use_nonce = true;
        $this->set_rules('nonce', 'Nonce', 'required|valid_nonce');
    }

    /**
     * Make sure the nonce is valid.
     */
    function valid_nonce($str) {
        return ($str == $this->CI->session->userdata('nonce') &&
                $str != $this->CI->session->userdata('old_nonce'));
    }
}

All you have to do now is open the form with form_open in your view, load the library in the controller and call the nonce method. That should do it! A remaining potential problem is that this will not work with more than one form at a time, though I’ll have to leave that as homework for you guys. Comments are open!

Image from the Open Clip Art Library.

To compare the same functionality in the two languages I used the really awesome php.js library, which sole purpose is to replicate as many PHP functions as possible using only Javascript. The tests were then run three times each in two different browsers, Firefox 3.6.6 and Opera 10.54, on my MacBook (Intel Core 2 Duo 2.4 GHz with 4 GB of RAM). The values presented are the average of these runs (for PHP I averaged all the six results).

PHP really kicks ass when it comes to hashing, being about 60 times faster than Opera and a whooping 320 times faster than Firefox on the MD5 hashes. When it comes to calculating the square root it’s not as great though. Opera is about 14 times as fast and Firefox is twice as fast as Opera, so if you’re gonna be crunching numbers you might want to consider letting your users’ browser do the heavy lifting.

For the summation test I created an array of 30 000 objects with two attributes, one name and one value, and the same array was used for Javascript by JSON-encoding the PHP variable. Javascript won this round as well, however, to be fair, my guess is that the reason for this is that JS objects have less overhead than their PHP counterparts and not so much it’s mathemagical powers (though that would go well with the square root awesomeness).

Lastly the sorting of an array. Once again the same array was used for both languages, but this time it’s a win for PHP. It’s a close call though, and especially the Javascript powerhouse that is Opera is not far behind.

So this is not the most scientific test around, but I still think the results are pretty interesting. Comments are open, any great ideas of how we can use this for web development or did I just waste five minutes your time?

According to the Mozilla wiki, the first beta will be released tomorrow, but after running the nightlies I have my doubts about it. In any case it seems unlikely we get to admire the overhauled UI in the very near feature. The nightly releases includes a choice to move the tabs on top, however it looks really crappy at the moment (none of that Safari 4 beta goodness which Apple gaveth and tooketh) and besides that I haven’t noticed any design changes.

Another feature that’s missing from the alpha but which is likely to make an entrance in the final product is Jetpack, a new plugin architecture based on web standards. Jetpack is supposed to be more lightweight and won’t require a restart to start working.

Mac-users out there should all rejoice! Out-of-process-plugins are coming to us as well, a feature brought to Windows and Linux users with release 3.6.4. It has been said that version 4.0 would bring full tab process separation, however it seems to me it’s been rather quite on that front lately, so my guess is OOPP will have to do for now as it takes care of a large portion of the crashes. Though as we are moving away from plugins and towards standardized formats such as WebGL, JavaScript and HTML5, I do believe separating tab processes is inevitable.

Oh, and more UI updates! The add-on manager has been moved from an annoying dialog to a super-sexy tab. Well, a tab at least. Some work still remains, but it looks good and I personally appreciate the tabbed approach. Enter about:addons in the location bar and – bam! Speaking of the the Awesome Bar, a neat little feature that has been added is Switch-to-tab. For those of us having trouble keeping track of all open tabs, it’s not unusual to open up the same page twice. Now the Awesome Bar will also search your open tabs and allow you to simply switch to another tab.

For web developers, I’d say the most influential features are the additions of WebM video format, WebGL, CSS transitions, better HTML5 support, Web Sockets and IndexedDB. As usual it will take some time until we can actually make good use of these additions for most sites, but the first step must always be taken by the browser developers.

My hope is that we will also see the integration of Mozilla Sync, previously called Weave, the syncing application which along with Firefox Mobile and Firefox Home will really help spread the Mozilla love across platforms.

EDIT: The previously mentioned Account Manager seems way cooler than I originally thought! Basically it will allow the browser to handle registrations on sites.

I am not in any way affiliated with Mozilla, and since Firefox 4.0 hasn’t even reached beta yet, much could still happen. I do, however, hope this made you as excited as I am about Firefox.next!

My first attempt at this – and please remember this was a long, looong time ago, in a simpler time – was to simply store the username and password in a cookie. Yes, that’s right, store the user’s credentials in plain text. The security concerns are obvious, a simple cookie theft would give the attacker everything he needs without having to think twice, and as if that wasn’t enough there is a high risk that the same credentials can be used to access other sites since very few people actually use different passwords for every site they register on. Luckily this site never reached an audience..

By storing the password hash we will at least take care of the leaked credentials issue, as long as we use a decent hash algorithm and salt the password properly (a simple md5 is not good enough, but more on this another time), thereby taking the likes of simple dictionary attacks out of the equation. The attacker can still access the account however.

Fact is that a compromised “remember me”-cookie will always allow an attacker to gain access to the account to which the cookie belongs. What we want to do is mitigate the impact. For example, we want to make sure that a malicious user cannot access someone else’s account and lock them out by changing the password. For these types of actions that concern the privacy and security of the user we want to make sure that the authenticated user actually knows the password. As long as we do this, the above is a pretty decent solution.

An even better, though slightly more advanced, solution is to never even store the password, hashed or not, in the cookie. Instead a randomly generated token can be stored in the client cookie as well as in the application database upon login. The next time that same browser visits the site the token and username/user ID, whichever you prefer, from the cookie can be checked against the server and if they match we have a valid login. This is a very brief summary of the points made in Charles Miller’s post Persistent Login Cookie Best Practice and Barry Jaspan’s improvement of the same in Improved Persistent Login Cookie Best Practice. This is about as safe as you can get as far as remembered logins go.

The point I really want to make is that there is no perfect solution for this and you should bear in mind that for any site requiring a high level of security a “remember me”-option is a big no-no, plain and simple. For any other site it’s a decision that must be made by you as a developer, weighting user convenience against any security implications.

Image by ilmungo, licensed under Creative Commons.

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.

Actually, the use of a nonce also prevents an attack called CSRF, Cross-Site Request Forgery. Without going into detail, this means a malicious site can potentially perform CRUD operations with your credentials on a site you are currently logged in to. The idea to prevent this is to generate a nonce word that is sent with the form and stored at the server, making sure that the request is made using our form. This is basically what we wish to do:

1. Generate nonce
2. Save nonce in a session variable
3. Add a hidden form field containing the nonce
4. Validate data and nonce
5. If nonce is valid, handle data and mark nonce as inactive

The key here is the validation of the nonce. There are two things to consider, one is that we should not allow the same form to be posted twice and the other is that the form must know what the current nonce is. This means for every request we need to have the current and, if it exists, old nonce saved in the user’s session. Also note I am assuming the sessions are stored in a database, since if they are not you probably have bigger problems.

To solve this problem I have extended the CodeIgniter Form Validation library so that it can handle this extra layer of security.

class MY_Form_Validation extends CI_Form_Validation {

	function __construct()
	{
		parent::__construct();
	}

    /**
     * Create a new unique nonce, save it to the current session and return it.
     *
     * @return string
     */
    function create_nonce()
    {
        $nonce = md5('nonce' . $this->CI->input->ip_address() . microtime());
        $this->CI->session->set_userdata('nonce', $nonce);
        return $nonce;
    }

    /**
     * Mark the nonce sent from the form as already used.
     */
    function save_nonce()
    {
        $this->CI->session->set_userdata('old_nonce', $this->set_value('nonce'));
    }

    /**
     * Set form validation rules for the nonce.
     */
    function nonce()
    {
        $this->set_rules('nonce', 'Nonce', 'required|check_nonce');
    }

 	/**
	 * Validation rule for making sure the nonce is valid.
	 *
	 * @access	public
	 * @param	string
     * @param	last used nonce
	 * @return	bool
	 */
	function check_nonce($str)
	{
        return ($str == $this->CI->session->userdata('nonce') &&
                $str != $this->CI->session->userdata('old_nonce'));
	}

}

Also, I extended the form helper to include a function for generating a new hidden form field with a unique nonce:

/**
 * Generates a hidden field containing a nonce.
 *
 * @access	public
 * @return	string
 */
if ( ! function_exists('form_nonce'))
{
	function form_nonce()
	{
        $CI =& get_instance();
        $CI->load->library('form_validation');
		$field = '<input type="hidden" name="nonce" value="'
            . $CI->form_validation->set_value('nonce', $CI->form_validation->create_nonce())
            . '" />';
        return $field;
	}
}

Last but not least I’ll show you how to use it in a controller method, in this case called add.

	function add()
	{
		$this->load->library('form_validation');
		// Set validation rules here..
        $this->form_validation->nonce();

		if ($this->form_validation->run() !== FALSE) { // If validation has completed
            $this->form_validation->save_nonce();
			// Handle the validated post request
			redirect('controller/method');
		}
	}

This is not a subject I’d consider myself to be an expert in, so any input on the validity of this library is greatly appreciated. This is something that might very well get included in future versions of CodeIgniter, and it should, but until then I hope this is a good alternative.

Image from the Open Clip Art Library.

So, the date_parse_from_format takes a date format and a string and parses the date to an associative array. Along with this I used the native checkdate which takes the argument month, day and year and tells you whether or not it is a valid date.

class MY_Form_Validation extends CI_Form_Validation {

	function __construct()
	{
		parent::__construct();
	}

	/**
	 * Validate date according to the specified format.
	 *
	 * @access	public
	 * @param	string
     * @param	date format
	 * @return	bool
	 */
	function valid_date($str, $format)
	{
        $date = date_parse_from_format($format, $str);
        return checkdate($date['month'], $date['day'], $date['year']);
	}

}

The valid_date function can be used by anyone sporting a PHP 5.3 install on their web host. Since I’m using CodeIgniter I simply put this function in MY_Form_Validation, which means I can easily use this function like any standard CI validation function, i.e.

$this->form_validation->set_rules('birth', 'Birthday', 'valid_date[d-m-Y]');

This is a really handy trick for those otherwise (for me, at least) nasty date validations.

Image from Crystal Clear icon set by Everaldo Coelho.

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.

<?php  if (!defined('BASEPATH')) exit('No direct script access allowed');

class MY_Router extends CI_Router {

    function MY_Router() {
        parent::CI_Router();

        log_message('debug', "Custom Router Class Initialized");
    }

 	/**
	 * Validates the supplied segments.  Attempts to determine the path to
	 * the controller.
	 *
	 * @access	private
	 * @param	array
	 * @return	array
	 */
	function _validate_request($segments)
	{
		// Does the requested controller exist in the root folder?
		if (file_exists(APPPATH.'controllers/'.$segments[0].EXT))
		{
			return $segments;
		}

		// Is the controller in a sub-folder?
		if (is_dir(APPPATH.'controllers/'.$segments[0]))
		{
			// Set the directory and remove it from the segment array
			$this->set_directory($segments[0]);
			$segments = array_slice($segments, 1);

			if (count($segments) > 0)
			{
				// Does the requested controller exist in the sub-folder?
				if ( ! file_exists(APPPATH.'controllers/'.$this->fetch_directory().$segments[0].EXT))
				{
					show_404($this->fetch_directory().$segments[0]);
				}
			}
			else
			{
				$this->set_class($this->default_controller);
				$this->set_method('index');

				// Does the default controller exist in the sub-folder?
				if ( ! file_exists(APPPATH.'controllers/'.$this->fetch_directory().$this->default_controller.EXT))
				{
					$this->directory = '';
					return array();
				}

			}

			return $segments;
		}

		// Can't find the requested controller...
		if( isset($this->routes['fallback_controller']) AND $this->routes['fallback_controller']) {
			$uri = explode('/', strtolower($this->routes['fallback_controller']));
			$uri = array_merge($uri, $segments);
			$this->_set_request($uri);
			return $uri;
		} else {
			show_404($segments[0]);
		}
	}

}

Most of the code above is copied from the core Router class, the only thing changed is below the last comment. This method does exactly what the PHPdoc says – it validates a request and decides which controller should be responsible for it. Normally though, it will just display the 404 page if no matching controller is found, but this is where our magic happens. We just check if a fallback controller has been set and if so, load it with any arguments from the URI.

Easy enough right? So all that remains is setting the fallback, which is done in application/config/routes.php where we add the following line (with the choice of controller up to you of course):

$route['fallback_controller'] = "loader/load";

I’ll leave writing the actual controller to you guys though.