Posted on
by

Over the past few weeks I have been helping Curverider develop the next generation of Elgg products, the first of which to be released is elggVoices – a cross platform short messaging tool.

One of the key features of elggVoices which I have been heavily involved in developing is a powerful and fully featured API. This API lets you read and post messages (shouts), search for channels, find all shouts on a given subject etc.

Getting the resources

Over the next few weeks we will be building this out with example code, client libraries etc. The first step is to get yourself over to the developer centre and take a look at the resources available. At the very least you should download the API documentation, this explains what API calls are available and what parameters they take.

API Keys

In order to be able to use the API, you will require two keys – a public API key, and a secret key. To obtain your keys, you can sign up for some at the developer centre.

The public API key is a way to identify your client with the elggVoices server, while the secret key is used to sign your api call and should be kept safe.

Making an API call

Once you have got your keys, you can begin making elggVoices API calls by using the REST endpoint at:

http://elggvoices.com/api/v1/

By far the easiest way to do this is to use one of the client libraries, however in the event a library hasn’t been written for your preferred language (or you fancy writing one), you are going to have to construct a raw query, as follows…

An API call is either a GET or a POST request, with API variables passed as a URL encoded string on the GET line. The POST data should be used for queries which expect large data blocks (file transfer etc).
An example api call might look like this:

http://elggvoices.com/api/v1/?method=example.method&format=xml&foovar=bar

Where method is the method call you are making, and format is the desired reply format (xml,php,json). These required variables can then be followed by an arbitrary list of other parameters expected by the API call.

Tomorrow I will show you how to construct a HTTP request using custom request headers, and to construct the all important HMAC signature.

Posted on
by

With the appropriate head nod to Ben and Dave, I wanted to make a quick post to draw your attention to Elgg and ElggVoices.

I’ve been doing a lot of the development on these projects over the past few weeks.

It is still a little hush hush so I can’t go into a lot of detail, but they’ve been exciting projects to work on and I shall no doubt be writing about this some more.

Posted on
by

While I do believe some of the analogies to be somewhat erroneous, I find myself broadly agreeing with the points raised in this article about current security practices.

We in the industry often find ourselves focusing on the more technical issues – patches, penetration testing etc. These fall well within the IT department’s sphere of understanding. They are sexy issues.

Certainly more interesting than matters of staff training, but as the article points out this is likely to be a much bigger win than ensuring everyone is using 28 character passwords or that company computers get patches the second they are available.

“Employee training sometimes gets a bad rap because it doesn’t alter the behavior of every employee who takes it,” he said. “But if I can reduce the number of security incidents by 30 percent through a $10,000 security awareness program, doesn’t that make more sense than spending $1 million on an antivirus upgrade that only reduces incidents by 2 percent?”

I am a big fan of the “strength in depth” approach to IT security and I believe that one should never rely too much on one technique. It doesn’t hurt to lock things down – decent passwords are certainly not going to do any harm – but I agree the big hits are probably going to be elsewhere.

However all the fancy security software in the world is not going to stop untrained staff doing something ‘unfortunate’ like sending the bank details of 25 million people through the post on two unencrypted CDs.

Crucially, for real security I think one should plan for failure and make sure that it is not the end of the world if something does happen. Backups, encrypting confidential data, as well as ensuring you have a firewall set up and configure correctly are all parts of a consolidated defence.

In short. Make sure your doors and windows are locked, but keep valuables out of sight and make sure you’ve taken out an insurance policy… and tell your flatmate not to let dodgy masked men with “swag” written on a sack wander around your apartment.