WebHookWebmention, as well as the legacy Pingback, provide a way of notifying a third party site that you have made some reference to something on their site. So, for example if I reference somebody elses blogpost in mine, that blog will be notified and my reference may appear as a comment on the post (unless they’re blogging on a passive aggressive silo like Google+ or Facebook, or their blog uses Disqus, which is, in many ways I won’t go into now, the suck).

Pingbacks, and increasingly Webmention, are supported by most major web frameworks and blogging platforms, but adding them to a home rolled platform can be a little bit of a faff, especially if these platforms are build on static HTML.

So, inspired by Pingback.me written by Aaron Parecki, I wrote a bit of middleware that can be installed on a web server with minimal fuss, and can provide pingback/webmention services to other sites.

The reason I didn’t use Pingback.me was that I needed something quickly, I had reasons why I didn’t want to install an entire Ruby stack, and I needed the webhook functionality for a couple of projects (including some funky node.js dataset regeneration to tackle some scalability challenges, but that’s a different story).

Setup

One of the main requirements for pingback2hook was ease of setup, which I hope I’ve achieved.

  1. Start by checking out the source code from the github repo here, and place this on your web server.
  2. You’ll need to have PHP 5.3 running with mod-rewrite, and also CouchDB (to store pings), which on Debian systems, should be a fairly straightforward setup.

    apt-get install apache2 libapache2-mod-php5 couchdb; a2enmod rewrite

  3. If you’re running pingback2hook on its own subdomain, you should be up and running, but if you’re installing to a subdirectory of your site you’ll need to modify the RewriteBase in .htaccess.

Enabling pingback and webmentions on your site

Once you’ve got the software up and running somewhere, you can then start enabling pingback support in your sites. This is a two step process:

  1. On the pingback2hook server, define an endpoint for your site in a .ini file. This file will define the endpoint label, a secret key for communicating with the API, and zero or more webhook endpoints to ping. E.g.

    [mysite]
    secret = "flkjlskjefsliduji4es4iutsiud"

    ; Zero or more webhook endpoints
    webhooks[] = "http://updates.mysite.com"
    webhooks[] = "http://data.mysite.com"

  2. On your website, declare the necessary hooks in your metadata, either by headers:

    // Webmention
    header('Link: <http://pingback2hook.myserver.com/webmention/myendpoint/>; rel="http://webmention.org/"');

    // Pingback
    header('X-Pingback: http://pingback2hook.myserver.com/pingback/myendpoint/xmlrpc');

    And/or in the header metadata…

    <html>
        <head>
            <link href="http://pingback2hook.myserver.com/webmention/myendpoint/" rel="http://webmention.org/" />
            <link rel="pingback" href="http://pingback2hook.myserver.com/pingback/myendpoint/xmlrpc" />
    
            ...
    
        </head>
    
        ...
    
    </html>

Once set up, you will get an entry in the database for every pingback or webmention a given permalink receives. If you’ve defined some webhooks, these will be pinged in turn with the JSON content of the ping.

Viewing your pingbacks

To view your pingbacks you can either make a direct query of the couch database (default: pingback2hook), or make use of the API.

Currently, you can query the API via its endpoint at https://pingback2hook.myserver.com/api/myendpoint/command.format, passing any required parameters on the GET line.

At the time of writing only one command is supported, but I’ll add more as I have need to:

Command Parameters Details
latest.json|jsonp target_url, limit (optional), offset (optional) Retrieve the latest pings or webmentions for a given permalink url.

To make the query, you need to authenticate yourself. This is done very simply by passing the ‘secret’ for the endpoint in your request header as X-PINGBACK2HOOK-SECRET: mysecret. This is very basic security, and your code is being sent in the clear, so it goes without saying that you should ONLY make queries to the API via HTTPS!

Have a play, and let me know what you think!

» Visit the project on Github…

IFTTT (short for If This Then That) is a very powerful service that one can use to hook a number of different cloud services together in cool ways, and it’s a service I make a fair amount of use of.

Like many of us who make use of cloud services, the Snowden revelations, that the US and UK intelligence communities had hooks into all the major cloud services (or perhaps a better word would be “confirmations”, since many of us suspected this was going on for a while), have given me pause to re-evaluate the services I use and trust.

So then, what of IFTTT?

With all the hooks it has into other services, it does seem to represent the ultimate in back doors. Out of necessity of function, the permissions granted for each service are quite wide ranging, and we only have it on faith that they won’t be abused. Ok, so it’s not as bad as them knowing my password, since I can click a button and revoke access at any time, but until then IFTTT have full access.

As a US company, and through no fault of their own, IFTTT are compromised when it comes to security, since they’re all backdoored by the patriot act. I suspect that if they haven’t been forced to share access to accounts, it’s only because they are still relatively small fish (when compared to the likes of Google) and are only really used by the technical subset of internet users. But as they grow, it’s only a matter of time before they appear on someone’s radar.

In addition, their business model has always been a little bit of a head scratcher. I suspect the whole service came about from a “wouldn’t it be cool if…” kind of conversation, rather than a set agenda to make money (quite right too), but servers don’t pay for themselves, and I do wonder how long it will be before In-Q-Tel come calling.

Of course, it may be moot, since most of the services that IFTTT connects to are also US based, and for that matter, other countries are almost certainly forcing backdoors into their cloud services too.

Still, it’s got me pondering self hosted alternatives… any nice #indieweb projects out there?

Screenshot-Dashboard - Google Chrome So, the other week I made a simple security device for my house, using a Raspberry Pi, that will (when I have a moment to wire it up), give a read out before I leave the house telling me if I have any windows or doors open.

Since I’ve been coding this Home API thing, the next obvious step is to wire the it up to the API so other things could make use of the data.

The first step was to modify the code running on the Raspberry Pi to transmit the status of each switch to a central server as a JSON POST request whenever something changed. On the server, I wrote a plugin which accepted this payload and stored for display, using the newly coded CouchDB support. This means that Home.API doesn’t have to poll the device, which would be more complicated and less efficient.

Sending data Home.API

Here is the client code, complete with Home.API integration:

The important lines of code are between lines 68 and 78. These lines check whether an update needs to be sent (we check for a state change in one of the lines we’re monitoring, and raise a flag if it is different from the last pass), and then package up an array of results as a JSON object and fire it over to Home.API using HTTP.

In our plugin

On the server, our class endpoint is loaded, and our decode method called. For efficiency we store this in a NoSQL database, which our display function getAll() just echos the contents off.

public function update() {
$result = json_decode(\home_api\core\Input::getPOST());

if ($result === NULL)
throw new \home_api\plugins\PluginException(i18n::w ('raspberrypidistw:exception:no_json_data'));

// Decode status
$this->status = array();
foreach ($result as $key => $value)
$this->status[$key] = $value;

// Create couch store
$uuid = \home_api\storage\nosql\NoSQLStorage::generateUUID($this, 'LastValues');
$couch = \home_api\storage\nosql\CouchDB::getInstance();

// See if there is an existing status
$latest = $couch->retrieve($uuid);
Log::debug("Retrieved: " . print_r($latest, true));
if (!$latest)
$latest = new stdClass();
$latest->status = $this->status;

// Store revision
Log::debug("Updating UUID:$uuid with " . json_encode($latest));
return $couch->store($uuid, $latest);
}

Pretty simple, have a play!