Hey all. As part of ongoing work I’ve put a couple of contributions back to the wider Open Source community. Read on for details…
As many of you will be aware I’ve been working on a couple of new API for interaction with MarkLogic. These are my MLDB NodeJS JavaScript API and my mldotnet C# .NET API.
For the NodeJS API I had to roll my own authentication wrappers for HTTP communication because the ones that existed were inadequate for clients (they provided Basic and Digest to servers). For my .NET API I was keen to avoid doing the leg work again, and to use any available popular API that would help both in communication and in marshalling to and from objects.
I found a great project in ServiceStack which provided me with all I needed… Only as it turns out their JsonServiceClient (and other clients) didn’t have Digest authentication either – they had a wrapper for server endpoints only.
Thankfully though as I’d already done the hard work in MLDB it was just a case of refactoring the Digest auth code for .NET and applying it. I forked ServiceStack and added in detection for server authentication – prior to this it assumed all auth requests were HTTP Basic. I managed to do this with very little impact to the clients, and so I submitted a pull request. This has now been accepted and so will be in a future binary release of Service Stack for all to use for accessing any service that requires a Digest protected backend.
I’ve been using ServiceStack for my .NET API, but I’ve also been writing a File Sync app that uses it. The option I chose was the popular SparkleShare library. This is based on Git but has the advantage of a pluggable backend model and support for XML plugin definitions to make selection of a backend easier.
Unfortunately as no one had created a non-git based backend before, there were a few areas in which the code prevented a completely new backend from being linked. The first of these is that SparkleShare has until now required a very specific URL format (ssh+mybackend:// …), and this was parsed to determine which backend plugin to use. This wasn’t compatible with a ‘normal’ URL like http://admin:admin@localhost:9094/ which is the format you’d most likely use against a MarkLogic type service.
There was a backend tag supported in the plugin XML definition but this was being ignored by the code. Again I forked the repo and made sure this value was being checked and obeyed if present. Also, SSH keys for the remote server were being checked, which of course causes a failure because the MarkLogic server doesn’t use SSH keys for HTTP communication, and so checking for keys failed, causing the backend plugin to fail.
I added a couple of flags that backend creators can set to ensure the URLs aren’t parsed and SSH keys aren’t checked. This worked, but the original author found it a bit clunky, so he’s gonna subclass the FetcherBase class with FetcherSSH – this means I can subclass FetcherBase (with no SSH actions) and his FetcherGit will subclass FetcherSSH. This actually is a bit nicer so can’t blame him for the change. Again this code will wind its way in to a new SparkleShare build soon.
This all of course makes me feel warm and fuzzy inside. Not contributed anything substantial back to an opensource project in ages, so it’s really good to find two quick but useful ways to help in the same week. I hope others will find it useful. I would think the Digest auth client change will be very popular. (Not least because it is transparent and requires no client code changes).
In the meantime my projects continue at a pace. I hope to have something pretty awesome to show at MLW13, so make sure you come to my Lightning Talk on the MLDB and MLDotNet APIs on the morning of Tuesday 9th April!
When I get some time I’ll work in my server auth detection back in to MLDB so you don’t have to specify the underlying security mechanism before connecting to a server, and will fork the wrapper code as a separate project for others to use.
Happy coding!
Adam's Deep Technology Blog 