Posted on
by

failwhaleIt seems like just the other day when I had to change a whole bunch of my passwords thanks to LinkedIn having it’s password database stolen by crackers, and now I’m having to do it again. This time it was Twitter that dropped the ball, but I am at least grateful that they’ve publicised the incident so widely.

Username/Password systems suck, I’ve written about this before. We should, as an industry, aim to move past them as quickly as possible, and it’s nice to see some attempts at this (although, a lot of those attempts are attempts to centralise identity in one form or another).

Like most people, I did recycle passwords on a number of services, and yes I know this was bad, but I only have a limited space in my head and I don’t enjoy having to remember long strings of alphanumeric characters. The main issue I’m having with this latest breach, other than the hassle of having to go around and change a bunch of passwords again (which is largely my fault I admit), is that Twitter, like Facebook and Google, can be used as a way to log into other services via OAuth.

This is very handy, and means that you can quickly sign on to a 3rd party service without having to create yet another password to remember. However, the downside, is that this central identity MUST be secure. Facebook and Google both add extra security to their accounts by having 2-factor authentication systems in place, so, when you access your account via a new device, you have to go through an extra security challenge – typically, entering a code sent to your phone or from a key generator app.

Twitter, on the other hand, doesn’t have this extra level of security. This means that the crackers could have access to not only your twitter account, but also any 3rd party service you’ve used twitter to log in with.

This is a big deal.

Personally, I think that any service that provides OAuth logins to other services, but doesn’t provide 2-factor authentication, is being somewhat irresponsible, and I really hope that Twitter fixes this with the utmost urgency. I for one will be using my Google account more…

Posted on
by

Over the past few weeks and months I’ve had to cause to write, update and dust off a number of Elgg plugins that I’ve had kicking about. As a good open source citizen I’ve stuck them up on github so others can have a play.

Here they are, in no particular order:

» H5F 1.8

This is an Elgg wrapper around the H5F HTML5 form compatibility library written by Ryan Seddon.

This plugin lets you use handy HTML 5 form extensions like “required” and “placeholder”, as well as some of the new types like <input type=”email” /> in your forms and have them work in older browsers.

» Input Country

Input country is a wrapper around Ben Werdmuller’s phpCountryDropdown tool, and provides a handy dandy country selector input type.

Install this plugin to be able to take advantage of this in your forms.

» Profile Completeness

This plugin provides a view and a widget that displays the completeness of a profile based on the number of fields in the profile that are populated. This list of fields can be extended and modified based on a plugin hook.

I’ve used various incarnations of this plugin now for a number of clients, and since it keeps coming up I’ve tidied it up a bit and stuck it on github.

» Recaptcha

Lastly, here’s an Elgg 1.8 version of a recaptcha plugin I wrote some time ago.

It hooks into the Elgg captcha engine, providing captcha verification for registration and the “request new password” functionality out of the box. It also replaces the input/captcha view.

There are a couple of other recaptcha plugins, but I couldn’t find one which just provided the captcha and nothing else, so here’s mine.

That’s it for now, enjoy!

Posted on
by

Helping out a friend and colleague, as well as stretching my programming muscles with a language I don’t often get to play with these days, I’d like to introduce LoveNote Server.

LoveNote is a simple abstract message queue server which lets you pass an message payload to one of a pool of endpoints and receive a webhook callback with the result. You can specify that this message be delivered ASAP, but crucially you can also specify a date and time for the delivery.

How it works

It works by POSTing a bit of JSON to a webhook provided by the server that contains a delivery time, an array of servers to try, the payload and an optional callback URL.

When received by the server, the message is queued. When the delivery time is reached the list of servers is randomised and the payload POSTed in sequence until all servers fail, or delivery is achieved. If a callback is specified, a report is then POSTed back to the callback as a JSON blob.

Why this is useful

Simply, this provides a common message passing framework with a unified event driven API, simplifying your architecture somewhat. It is especially handy if you wanted a message to be delivered some time in the future, for example for a credit card renewal or email reminder, where beforehand you’d probably have to write a dedicated server process.

All you now have to do is listen to webhook pings.

What still needs to be done

This is an early version and was written to help out a friend with a specific need, and although I’ve gone on to use it in a couple of client projects, there are still a fair amount of enhancements that could be made.

Some obvious ones are:

  • Message IDs: Currently messages in the queue are anonymous. It’d be handy to have message IDs since this would allow more sophisticated process control of scheduled messages.
  • Cancel Control: Basic message control to cancel future queued messages.
  • Make message queues persistent: Currently the queue is held in memory, which is simple and fast, but far from ideal. We should periodically flush the queue to a persistent storage so that no messages are lost if a server goes down.

Get involved and send your pull requests to the usual place!

» Visit the project on Github…