[OPEN-ILS-DEV] [OPEN-ILS-GENERAL] automate offline patron download

[Jason Etheridge]

CC'ing OPEN-ILS-DEV

On Mon, May 10, 2010 at 5:36 PM, Andrew Tillman
<tillman at leecountylibrary.org> wrote:
> In Evergreen 1.4.07 is there a way to automate the "Download Offline Patron
> List" function with Windows Task Scheduler? Or should we be looking at
> another method?

Andrew, would you want the list to be updated periodically whether the
client logs in or not, or maybe every time the client logs in?

When this feature was written for PINES, the expectation was that the
list would be large and that pulling it down on demand for just those
who needed it (primarily bookmobile staff) would suffice for limiting
the use of bandwidth.  I think the implementation may have been naive.

As for your question, you could download the file containing the list
outside of the client (say, using curl or wget) via a CRON job or the
Windows Task Scheduler, save it into the user profile directory (where
ws_info lives) and rename it "offline_patron_list".  Then replace the
file "offline_patron_list.date" with a new one containing the time of
download in a format resembling this:

Wed May 12 2010 23:55:01 GMT-0400 (EDT)

(this is the stringified form of a javascript Date object)

Better would be to do an HTTP HEAD against the file instead of GET, to
test whether it has changed since it was last downloaded (we should
probably have the client do this as well).

For developers, here is the code behind the Download Offline Patron
List menu entry:
http://svn.open-ils.org/trac/ILS/browser/branches/rel_1_6/Open-ILS/xul/staff_client/chrome/content/main/menu.js#L861

And how it gets used in the offline interfaces:
http://svn.open-ils.org/trac/ILS/browser/branches/rel_1_6/Open-ILS/xul/staff_client/chrome/content/circ/offline.js#L128

What would be lovely is if we could break the file up and do something
similar to rsync, where the patron list could be updated piecemeal as
needed.  There's also a limitation now with loading the list into the
staff client, in that if the list gets too big and the workstation too
slow, you'll get Script Taking Too Long warnings that you have to
click through.  Multiple files, perhaps using a hash function with the
patron barcode, could allow us to load smaller files on demand and
improve the situation.

Any takers for development or funding of development? :)

Something else that may be worth thinking about, is that at the time,
the bad patron list wasn't considered "sensitive", since it only
contained barcodes and a 1-letter code for the status.  If a patient
hacker were to grab this list and try to use these barcodes, they'd
have to also guess the right passwords and chance upon the patrons no
longer being barred or blocked (and ideally, the login failure message
wouldn't leak whether it was a bad password or some other condition
that prevented login).

However, there is a tendency for libraries to push 4-digit PIN's as
passwords, and a known user barcode is a big piece of the puzzle
needed for a hacker, a much better situation for them than randomly
generating usernames and barcodes to try.

If any of this is worrying you, then one quick roadblock a system
admin could throw up is to put basic authentication on the apache
directory serving the bad patron list.  The staff client will prompt
for the basic auth credentials.  They could also implement IP-based
restrictions on the file, and use URL re-writing to force the use of
SSL.

Yet more things to think about: some ILS's also preserve fine
information for patrons for use in offline mode.  We don't, and I
don't know of an easy way off-hand to make that scalable for large
consortia, but it may be something folks would like.

Anyway, thanks for letting me hijack your email thread to ramble about
the bad patron list. :-D

-- 
Jason Etheridge
 | VP, Tactical Development
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  jason at esilibrary.com
 | web:  http://www.esilibrary.com