Category Archives: Software

Posted on
by

Just a quick update to point you good folk over to a couple of Idno plugins I’ve put up on github.

The first, LoginSyslog, is a simple plugin that outputs login events (success and failure) to the Auth.log, in much the same way as my Elgg fail2ban plugin. This allows you to audit login attempts on your Idno site, as well as use a tool like fail2ban to protect your site from brute force attacks.

The second, Pingback, adds support for incoming Pingback. Idno primarily supports webmention as a notification mechanism, and while legacy support for outgoing pingbacks, however incoming pingback support was missing. This plugin adds the missing functionality, meaning your Idno site will play nicely with WordPress and similar.

Happy hacking!

Posted on
by

LinkedIn-Logo-02I was doing some work on a client website the other day, when the OAuth login code I was using to provide “log in via linkedin” support inexplicably stopped working. It would seem that linkedin had a (temporary) problem with their OAuth1 api.

A quick google, and I found that LinkedIn’s OAuth 1 api has been superseded, and I feared that it had finally been switched off. Since there was no word from LinkedIn, and I needed to get functionality working for my client, I rewrote the connector.

This plugin provides “Login via LinkedIn” functionality to Elgg 1.8, enjoy!

» Visit the project on Github…

Posted on
by

The other day I sketched out some notes on how friend/follow and subscribe might work in a distributed social network such as Idno (I have since hacked together some plugins based on those notes).

So, I thought I’d sketch up some thoughts on how private and friend only posts might work in a distributed social network:

Outline specification

  • On account creation (or if there isn’t a key present) a key pair is generated, this key pair is used to identify a user’s profile to that user’s friends.
    • I’m not sure exactly what kind of key this should be at this point, although I’m leaning towards a PGP key pair, although OpenSSL has its merits (of course, there is no reason why we can’t use multiple technologies).
    • We’ll probably have to have the private key stored on the server for the purposes of signing, although there’s no reason why these have to be your main keys.
  • When Alice follows Bob, as described in my previous post, they both pull the public keys from each other’s profile as part of that exchange, which have been marked up using Microformats 2. Any keys found are saved against the record of that user.
    • For security, we probably want to do some sort of key validation here; perhaps key fingerprint, or perhaps better some web of trust based on mutual friends…
    • How key revocation might work is an open question, but I think the easiest way might be for Alice to send another subscription request to Bob, and have that re-trigger this process, rather than (as happens at the moment), returning an error that Alice is already subscribed to Bob.
  • When Bob writes a friends only post he lists Alice’s profile UUID in a list of people who can view the post, then ping’s Alice’s endpoint.
  • When Alice visits Bob, or Alice’s site visits Bob’s permalink, it identifies itself by signing the request using her key. If the signature is valid and belongs to a key for a user for which Bob has allowed access to the permalink, the data is displayed, otherwise a HTTP 403 code is returned.

Just some rough thoughts for now, let me know your thoughts!