Category Archives: mediawiki

Down and dirty with OpenID

Posted on by

I’ve spent the last few hours (after getting home from a swift pint in the pub admittedly) having one of those satisfying coding experiences where the dots just start joining up… I took the very nicely written OpenIDenabled PHP library and bolted it on to the authentication routines for PROD.

The technical principles behind OpenID are simple enough: the user tells your application their openid URL, the app asks the relevant provider if everything is ok, the provider comes back and tells the app a whole bunch of stuff saying that the user is kosher (or halal or whatever it says in their profile).

The latest version of the toolkit made this a breeze – coming as it does with working examples and very well documented code. Most of the work was putting in a few new hooks in my authentication script to catch both ends of the transaction, copying and pasting some code from the example scripts to create the consumer object and set it flying and finally catching the response at the end and telling my application that the user is now logged in.

As with most quick work there is still quite a bit tidying up to do – particularly around how I associate existing users in the LDAP directory with their OpenIDs… At the moment I’m just not bothering. Useful error messages would probably be a good idea too! Testing it with a few different providers is also a must.

One gotcha I discovered was that at some point the exact recipe for doing Delegation must have changed and that the library is more fussy about this than other implementations I’ve seen and used. When testing using my own domain’s delegation which I’ve had set up for years it was consistently failing. This is not good news as there are probably thousands of people who still have it set up exactly as I did…

Another (Ubuntu specific) issue was that it was failing to authenticate against yahoo’s service because I was missing some bits of openssl… This was fixed with a quick sudo apt-get install openssl ca-certificates

Now I’ve had a few brushes in recent months with OpenID mainly around the web provision for the XCRI project – where we got OpenID working across WordPress, Mediawiki, and (through some rather cheap hacking) BBpress. It was however reliant on plugins for said apps and never really a very satisfactory experience – generating a long string of complaints from users getting very variable results depending on which provider they were using. Upgrading any particular component of the site seemed to just lead to more chaos.

Sadly I think that these variable experiences do rather detract from the potential that OpenID has to help us all better manage our online identities. That and the insistence of so many “providers” like Yahoo! and WordPress.com that they are just that, providers and not consumers. I’ve already got about 6 OpenIDs on the go without really realising – useful for testing but the exact opposite of the single authentication service goal. Tsk tsk.

Anyway… Now that I’ve actually tackled the problem at a slightly deeper level I’m feeling confident that over time we can not only iron out XCRI’s woes but also introduce OpenID across the JISC CETIS (and IEC) services in a reasonably robust way. The future looks rosy, the sky is blue, thunderclouds? What thunderclouds?

Mediawiki LDAP headaches part 6

Posted on by

Mediawiki has a useful LDAP Plugin. We have been using it on the CETIS wikis for some months now and it has been fine. The time came when we needed to promote various staff members to the rank of administrator so they can do things like import content and protect pages. In all honesty it wasn’t a hard thing to achieve: I created a new groupofnames entry called sysop in the LDAP directory and populated it with the names of our staff members. Adding the appropriate lines to the mediawiki configuration scripts after some trial and error resulted in the groups being syncronised and the appropriate people becoming appropriately powerful.

This is fine. BUT I’m not totally satisfied. What I really wanted to do was give all members of the staff ou (organisational unit) the sysop privilage – so I don’t have to start assigning more groups to people than they already have. There isn’t an easy way as far as I can see to make a group containing all children of an ou. Or at least if you can define the ou as a member of the group, no self-respecting implementation is going to realise quite what you’re getting at.

I’m left with the prospect of adding everyone to the group (which I’ll automate I suppose) – or hacking the plugin. Or I could re-structure the whole directory putting everyone in a single ou and using groups as the primary means of differentiating people. I don’t really want to do that.

Other ideas are (of course) welcome.

The cacher in the rye

Posted on by

Last Friday I “accidentally” upgraded the instance of Mediawiki on the server used by the design for learning site… And true to form things broke. The database needed an update, the custom skins were no longer working, the LDAP authentication broke and loads of stuff just was not happy. The last couple of days have involved quite a lot of time playing “whack a mole” trying to make these problems go away, re-building the skin, double checking the logins etc. A round of emails with an end user led to my also discovering that it was now using a server-side thing called memcached and that this was stopping mw delivering pages beyond the navigation bars. Clearly this is not how it ought to be – I’m sure memcached is a perfectly good bit of kit, but rather than spend yet more time working out quite what was wrong with it I went for simply disabling it. All _seems_ to be working now and the users content.

The silver lining to this cloud is that it brings the dfl installation more in line with the other cetis and intrawiki instances – and the even gooder news is that those instances were not affected at all. It may also be worth having a little re-jig of the mediawiki instances on the server to make the whole business of running a farm a little more resilient. But that is one for some other time.