ILS Authentication module

Update, 2012-03-01: New versions of this module for D6 and D7, now with SIP support courtesy of Jason Sherman, are available (attached below). We have submitted the ILS Authentication module as a full project on d.o. and are awaiting approval.

ilsauthen-6.x-1.2.zip30.13 KB
ilsauthen-7.x-1.4.zip28.34 KB


Works with Evergreen

Quite fantastically, actually! Out of the box!

This solves my issue of not being entirely sure how I was going to authenticate against our Evergreen ILS with our soon-to-be Drupal website.

Thanks for testing it out

That's good to hear. Thanks for testing it out.

You might want to mention

You might want to mention that in order for this to work with the III ILS, a library would actually have to have purchased the Patron API product, which is an optional product.

Yes, III Patron API is required

Bob, that's a good point, thanks. I'll include that in the revised README and the III driver. Alejandro has done some work on walking the III login form for authentication but I didn't incorporate his code into the III driver. I plan on doing that though, so just like with the Evergreen driver, the III driver will provide two options for authenticating users.

Code for III Authentication with no Patron API

I'm currently working on adding this functionality into the Drupal Millennium module; right now you can fetch the 6.x-2.x-DEV version to try it out NOTING that: (a) It might eat your site, so don't try it on a production server. (b) It probably won't work out of the box, unless you modify some of the regular expressions in

The module is here:

I need to arrive at module settings that'll work in (almost) every WebOpac regardless of settings, to ease barriers to entry to using this module. Testers are welcome!

When I have this working a bit better, I'll post back here =)

What should happen when this module is uninstalled?

I'd like some feedback on my plan to handle what happens when this module is uninstalled. Since this module creates Drupal accounts on the fly from external authentication sources, and does not store the account's password locally, once the module is uninstalled there will be no way for Drupal to authenticate these users against the originating external source. My plan is as follows (taken from the UNINSTALLATION section of my latest README.txt):

Accounts created using this module are converted to "regular" Drupal local
accounts (that is, the association between the ILS Authentication module
and the accounts is deleted). However, because the external authentication
source, and not the local Drupal, was managing account passwords, users of
accounts created by this module will not be able to log in after the module
is uninstalled. This is because on account creation, Drupal generates a
random password for users and stores it in the {user} table. ILS Authentication
never changes this original (random) password since it delegates
authentication to the external source.

After this module is uninstalled, the next time users of accounts it created log in,
they are presented with the standard Drupal error message that appears when
the supplied password does not work, i.e., "Sorry, unrecognized username or
password. Have you forgotten your password?". They then must request a new
password from the site in the usual manner.

Does anyone think this is an unreasonable way to handle accounts created by this module? The only other option I can think of is for this module to update the {user} table with the user's external password every time the external source authenticates them, thereby storing a copy of their external password. Then, when the module is uninstalled, they will not notice the difference since they will be using the same password that they used the last time they logged in.


I think requiring the user to request a new password might be the best way. That way, the user has some indication that the link between their online catalog account and their website account has been broken. If you just silently set their local Drupal password to the ILS password every time, uninstalling the module wouldn't cause the end user any issue at all -- until they changed their password on one site or the other -- then there would be quite a lot of confusion!

I think any organization that chooses to unlink their website authentication from their ILS authentication would have to seriously consider all the ramifications of doing so, however, and should definitely post a news entry informing all users of the change when it happens in order to prevent a flurry of support calls.

Speaking as a Library Tech, any unannounced change in the ways patrons interface with technological systems will always result in many many phone calls and e-mails. :)

Also, it looks like we are planning to use this on our new Drupal website, but we really would like patrons to be logged into our OPAC when they authenticate with Drupal using this module, so we'll probably try to figure out a way to make that happen so they can view/place holds, renew items, etc without having to log into the OPAC separately.

Thanks again!

Already added solution

All good points. A couple of weeks ago, I integrated the solution I describe in the previous comment but didn't update this page (some paid Drupal work took priority, but now I'm posing this comment on a new Mac paid for partly by that work!), namely that if the remote login is successful, this module updates the user's record with a hashed version of the password they entered. Now, when the module is uninstalled, the _local_ password is the same as the last valid password used to authenticate against the remote service.

It wouldn't be difficult to allow the local admin to control whether the remote password is stored or not. I certainly agree that any major changes in the way users authenticate should be explained clearly. In either case, some users are going to be SOL when logging into the Drupal site, so I guess it's a question of how the local library wants to handle this situation.

Your plan to allow users to view holds, renew items, etc. is commendable, and I think that as long as your ILS is open enough to allow a remote site to do this, Drupal is up to the job. In particular, the XML-RPC handling is extremely straight forward, since Drupal has a built in client and server. But whatever protocol/method you use, I doubt if you'll be limited by the Drupal end of the conversation.

I'm waiting to hear back from one site that wants to use Evergreen barcodes instead of usernames, but when I get that worked out, I'll post a new version of the module, hopefully one that will be functional enough to do some prerelease testing.

ILS Authentication update

It's been two months since I announced this module, and I've got it pretty much ready to set up as a contrib project on d.o. I've got to get my head around using their cvs but that's all that's holding me back.

Some features/fixes that have been added:

  • Sensible error handling when connecting to the remote ILS, using a general error-checking function that can be used by driver developers
  • Driver-specific, admin-configurable messages to display to externally-authenticated users when they request that their passwords be reset, useful for directing them to the ILS so they can change their passwords there
  • When the module is uninstalled, accounts created from the remote ILS are converted to regular local Drupal accounts, and users can still log in using their passwords from the last successful login against the remote ILS
  • Example SimpleTest suite to assist driver developers
  • Extensive code cleanup, checked with Coder module for conformance to Drupal coding guidelines

Thanks to everyone who provided feedback and help test the module so far.

ILS Authen .zip file updated

I've just replaced the -dev .zip package I originally posted with the latest version (May 4), as someone has asked for it. I still haven't started a project on d.o. but will get in gear and do so this week. This version integrates all the changes described in the previous comment.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <em> <strong> <h3> <h4> <h5> <h6> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <blockquote>
  • Lines and paragraphs break automatically.
  • You may post code using <code>...</code> (generic) or <?php ... ?> (highlighted PHP) tags.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Use [toc list: ol; title: Table of Contents; minlevel: 2; maxlevel: 3; attachments: yes;] to insert a mediawiki style collapsible table of contents. All the arguments are optional.

More information about formatting options

This question is for testing whether you are a human visitor and to prevent automated spam submissions.
  _           ____            _   _   _____ 
(_) __ _ | __ ) _ __ | | | | |___ /
| | / _` | | _ \ | '_ \ | | | | |_ \
| | | (_| | | |_) | | | | | | |_| | ___) |
|_| \__, | |____/ |_| |_| \___/ |____/
Enter the code depicted in ASCII art style.