About six months ago we signed a contract with Springshare beginning a relationship as a customer for their LibGuides service. LibGuides is vendor-hosted system for building and presenting subject guides, course guides, how-to’s, research tips, and more. Here at Mason, we’re calling the system “InfoGuides” and thus far we’re quite pleased with the product. It has given our public services librarians a very accessible way to begin experimenting with newer technologies even as they tackle a very traditional task (building a subject guide).
One nice feature is the ease with which librarians can add RSS feeds to their subject guides. Sprinkle a few relevant feeds around and suddenly your guide looks more active and the content is fresher.
Unfortunately, we’ve discovered that some feeds include links to restricted resources. When a user is off the campus network, the links included in the feed stop working. How to get those links to include our EZproxy server URL stem so even off-campus affiliates can access the resources.
It took a bit of digging but it turns out there is an EZproxy directive that does just what we want:
1. Don’t authenticate the user for the feed URL itself. Just retrieve the content.
2. As content is pulled from the feed server, rewrite any URLs in the content so they’ll point first to the proxy server.
So, when a librarian wants to put the “New Books Feed” from Safari books on a guide, the feed URL has our EZproxy URL stem added:
http://mutex.gmu.edu:2048/login?url=http://safari.oreilly.com/rss
How does it work?
We rely on the AnonymousURL directive within EZproxy (release 4.0a GA or later). Here’s the block from our config file that allows the RSS feed from Safari books to be correctly processed:
AnonymousURL -RE +http://safari.oreilly.com/rss T Safari books RSS feed D oreilly.com H safari.oreilly.com AnonymousURL -*
We still have one problem.
The LibGuides software offers a “subscribe to this feed” option whenever you include an RSS feed widget on a guide. Unfortunately, the link associated with this subscription is the same link we’re using to send the feed to our proxy server for “pre-processing” during page build. So if a user clicks on the “subscribe to feed” option, it goes to our proxy server and times out…
I sent a note to Springshare technical support asking for a way to handle this problem and suggested they just include a “proxy this feed” checkbox that would send the feed to defined system-wide proxy server during page build but then build the “subscribe” link with the clean URL. We’ll see what happens.
Update 8/26/08
Just received an email from Springshare. They intend to add a “proxy this feed” checkbox to their RSS widget so the feed will be fetched via the proxy server and then offer end users a “clean” (not proxied) feed for their personal subscription. That’s a quick response isn’t it? I’m really starting to like Springshare’s idea of support.