From the Oxford English Dictionary:

† bodge, v.

Chris Leach and I have had to bodge a fix for ebook URLs in our library catalogue, for a third time. I’m getting that feeling that we’ve bodged our way into a corner. (N.B. we’re going to upgrade Athens quite soon – I hope that once we can build our own WAYFless URLs to UK Federation-authenticated resources, on a *.lincoln.ac.uk root, we should be able to fix this problem ‘properly’. Until then…)

Here’s the problem and a list of our bodges to date:

We import MARC records for ebooks from Ingram’s MyiLibrary platform. They contain perfectly good, honest URLs (stored in MARC field 856$u), tweaked for Athens in the form (e.g.):

• http://www.myilibrary.com?Ref=Athens&id=115106

Next, to make sure our users see the correct Athens login option for the University of Lincoln…

…and not a generic Athens username and password box (from where the user would have to click on “Alternative login” and generally go round the houses to proceed)…

…we use MARC field mapping feature in our LMS (SirsiDynix Horizon – a feature which operates not unlike the e-journals A-to-Z’s “proxy mask” tool) to prefix every URL stored in MARC 856$u with our standard Athens cookie-setting prefix URL (N.B. this prefix is applied to all ebooks in the catalogue–in fact, any URL in 856$u–not just MyiLibrary ebooks):

• http://auth.athensams.net/setorg.php?id=LINCUNI&ath_returl=

This prefix combines with the contents of 856$u to give a compound URL, which is presented to the user as a hyperlink in user in HiP, our OPAC/web catalogue (e.g.):

• http://auth.athensams.net/setorg.php?id=LINCUNI&ath_returl=http://www.myilibrary.com?Ref=Athens&id=115106

Problem #1 – that compound URL doesn’t work. It returns an Athens error (presumably because Athens can’t tell whether the variables at the end of the URL belong to auth.athensams.net, or to www.myilibrary.com).

Bodge #1 – To avoid this error, the second part of the compound URL ought to be %-encoded (the A-to-Z’s proxy mask feature allows for this using {startencode}{endencode} pseudotags, but the Horizon MARC field processor doesn’t have anything like this afaik). So, we changed our import processes/record specification for the MARC records we get from MyiLibrary, %-encoding the contents of 856$u:

• http%3A%2F%2Fwww.myilibrary.com%3FRef%3DAthens%26id%3D115106

…giving a compound URL (including the field prefix) of:

• http://auth.athensams.net/setorg.php?id=LINCUNI&ath_returl=http%3A%2F%2Fwww.myilibrary.com%3FRef%3DAthens%26id%3D115106

This worked fine for users accessing ebooks from HiP.

Problem #2 – didn’t occur until we started using Talis Aspire as reading list software. When a user bookmarked a catalogue record from HiP, the %-encoded contents of 856$u were causing an error. See explanation here.

Bodge #2 – to fix this Talis Aspire error, we downloaded all of our MyiLibrary MARC records (using an SQL query to identify every record where 856$u contained ‘myilibrary.com’) and used MarcEdit to partially undo the %-encoding of the URL, to give:

• http://www.myilibrary.com%3FRef%3DAthens%26id%3D115106

…before re-uploading the doctored records into Horizon. This was enough to fool Talis Aspire into accepting the URL as valid, and as the reading lists prefix each online resource URL with a redirection URL of their (Talis’s) own, the net result is that users can link from a reading list to an ebook. (However, because the URL-as-stored-in-Aspire doesn’t contain the Athens cookie-setting prefix, some users will inevitably be sent to the wrong, generic Athens login page instead of the correct, University of Lincoln-specific one.)

Problem #3 – Most recently, when we started weekly exports of MARC records from Horizon into our new discovery service Find it at Lincoln (our name for the EBSCO Discovery Service) we discovered that the partial-%-encoding still wasn’t enough to produce a valid URL. Find it at Lincoln doesn’t prefix the ebook URLs in any way, and when users clicked on the ‘raw’, partially-encoded URL in a book record within the EBSCO service, they were getting a browser error.

Bodge #3 – this is where it gets very messy. As a short-term fix to stop users seeing the browser error every time they tried to access a MyiLibrary ebook from within Find it at Lincoln, we again exported all 1,300 or so MyiLibrary-matching MARC records from Horizon, and again edited the 856$u URLs using MarcEdit.

This time, we added the Athens cookie-setting prefix to each MyiLibrary URL, before re-uploading. We also then ran a separate export of the same records to a .csv file, which makes it easy to do a visual/formula-driven inspection of all 1,300-odd records to make sure there aren’t any duplicates/oddities/crud. This is a useful trick we’ll be using again!

So, the contents of 856$u now look like:

• http://auth.athensams.net/setorg.php?id=LINCUNI&ath_returl=http://www.myilibrary.com%3FRef%3DAthens%26id%3D115106

…as such, they should work fine in both the reading lists system, and in Find it at Lincoln (once the most recent weekly MARC dump has been processed by EBSCO). In HiP, however, they still get the MARC field prefix applied, and they end up with a double Athens prefix:

• http://auth.athensams.net/setorg.php?id=LINCUNI&ath_returl=http://auth.athensams.net/setorg.php?id=LINCUNI&ath_returl=http://www.myilibrary.com%3FRef%3DAthens%26id%3D115106

This double-dose of Athens cookie-setting doesn’t seem to do any harm, although I do know that Athens throws a wobbly if a user is referred to an authentication point too many times in quick succession – so I’m wary of leaving things as they are.

There’s also the problem that other ebooks (on our other main platform, Dawsonera) are still being pulled into Find it at Lincoln and the reading lists without an Athens prefix, so unless users have already encountered an Athens institutional cookie, they’re getting the ‘wrong’ Athens authentication point. To get technical, they will see the HTML login form for users with an OpenAthens MD = Managed Directory account. Otherwise known—though it’s not a term approved of by Eduserv—as ‘classic Athens’. At Lincoln we only create classic Athens accounts (with usernames beginning hum_______) in an emergency.

We could perform the same trick with all our other ebook records (several tens of thousands of records, for Dawsonera and a few odds and sods): identify and download them, incorporate the Athens cookie-setting prefix within 856$u, re-upload them, and ditch the Horizon field prefix rule entirely. But: if and when we change our methods of authentication we’d have to process all the records all over again (though to be honest, we’re getting used to it…), and I’m loath to hard-code authentication ‘noise’ into our MARCs.

Other options: we could look at alternatives to Athens authentication (UK Federation or IP/EZproxy) in the case of MyiLibrary; we could speak to Ingram to see if there’s anything that can be done about their slightly odd Athens session behaviour, and/or we could just get on with setting up a new OpenAthens environment that allows us to create proper WAYFless URLs instead of using the cookie-setting method, which is itself a bit of a bodge. We could also see if it’s possible to add proxy-mask-style behaviour to links in EDS (Find it at Lincoln) and Talis Aspire.

For the time being, it’s holding together with sticky tape. Don’t breathe on it too hard.