I am delighted to announce that we will be holding a virtual barcamp fringe event on Friday 24th July for all those people who can’t make our main event.

To give us some idea of the numbers coming we have tickets available on Eventbrite, so go grab yourself one!

Our main avenue is the event Friendfeed account here: http://friendfeed.com/barcamptransparency

We have prepared three virtual rooms for you to discuss issues related to:

  1. Open government – http://friendfeed.com/ff-bct09opengoverment
  2. Cyber-activism – http://friendfeed.com/ff-bct09cyberactivism
  3. Social media ethics – http://friendfeed.com/ff-bct09socialmediaethics

Later this week we will be releasing the first batch of tickets for the main event using the same system, more to follow so watch this space!

I am absolutely delighted to be able to announce that I have managed to confirm the venue for Barcamp Transparency. Barcamp Transparency will be held at the Oxford University Club on the 26th July!

This is a fabulous venue (the same one as Barcamp Apache Oxford), directions and other details can be found on our website.

I am also delighted to announce that Google has agreed to be the main sponsor for the event and will be covering the cost of the venue for us! Big thanks to all at Google and our other sponsors for making this event possible!

See you there on the 26th July!


View Larger Map

A new CAPTCHA approachOne thing we try and do when working on a new Elgg feature is – where we can – couple things together as loosely as possible and provide hooks for third party developers to extend Elgg and fill in any blanks.

A good example of where this has been done is the newly introduced Captcha functionality available in the latest nightly testing builds of Elgg.

The Captcha functionality is provided by a module which extends a view called “input/captcha“. This view is blank by default but is used in several places such as user registration and the lost password form.

This means two things; firstly that if a Captcha module isn’t installed or enabled then forms behave normally, and secondly it becomes a trivial matter for third party modules to provide their own Captcha functionality.

This same mechanism is how the URL shortener module works by the way.

Next, the Captcha module extends a number of actions to require a correctly validated Captcha code. This list itself is the product of a plugin hook which returns an array of actions which require Captcha validation:

$actions = array();
$actions = trigger_plugin_hook('actionlist', 'captcha', null, $actions);

...

function captcha_actionlist_hook($hook, $entity_type, $returnvalue, $params)
{
if (!is_array($returnvalue))
$returnvalue = array();

$returnvalue[] = 'register';
$returnvalue[] = 'user/requestnewpassword';

return $returnvalue;
}

The reason why the list of actions is provided this way is twofold, firstly it lets modules use Captcha functionality in their own code through a generic interface, and secondly it is harder to spoof than looking for some marker in the form code.

The Captcha itself injects a server generated token into the form, which together with the user’s response to the characters generated in an image are used to validate that the user is indeed human.

As we can see, Elgg asks to be provided with a Captcha if one is available by including a specific view, but is agnostic as to where (or indeed if) this functionality is supplied.

By using the techniques available to an Elgg programmer I was able to loosely couple the Captcha system to Elgg in such a way that a third party can easily use the same techniques to provide a more advanced module.

Happy coding!

Image “A new Captcha approach” by XKCD