Authentication: add PAIA (Patrons Account Information API)

[tzeumer]

PAIA stands for Patrons Account Information API and is specified here https://gbv.github.io/paia/paia.html. It works well since nearly four years (I tried offering it via SourceForge patch back then).

We use it live at https://www.tub.tuhh.de/en/study/reservations/. Some other libraries use MRBS with PAIA too. It would be nice to minimize local code changes (and explanations) by adding it in the official version. If tests are necessary, I could provide a library card + password - our PAIA is public.

I'm not sure if it is necessary to explain the "settings" somewhere else than in the file itself:

$auth["type"]           = "paia";

// Set your server without trailing slash
$auth["paia"]["host"]   = "https://paia.gbv.de/DE-830"; 

// Set any format for the display Name with #NAME and #BARCODE; falls back to Barcode if empty. 
// DO NOT CHANGE when productive with reservations (login and entries are connected by this!)
$auth["paia"]["format"] = "#NAME (#BARCODE)"; 

// (Deny user groups access; for example allow reservation only for faculty members and deny it for external users)
$auth["paia"]["restrict"]= array(29, 30, 31, 32, 33, 39, 40, 42, 43, 44, 48, 49, 60, 80); 

// As the entered login name
$auth["admin"][]        = "08300173390"; 

[campbell-m]

Thanks. I'll look at it over the next few days. In the meantime a library card and password would be useful for testing, both now and in the future when changes are made to MRBS. You could either post them here or send them to me at cimorrison at users dot sourceforge dot net.

[tzeumer]

Great, thank you very much for considering it.

I sent you a mail but it was returned. I triple checked it, but can't find an error. So I post them here. Since the account details could be used to login and create schedules to the MRBS at our homepage, I set the account to a group that I restricted via $auth["paia"]["restrict"]. So the login at our site won't work but it would work in a test installation.

• User: 08300173617
• Pass: 160424

You (and hopefully no one before you) could change the password at https://www.tub.tuhh.de/ext/lbspw/index.php?lang=en

Thanks again and best regards

[campbell-m]

Thanks. I've now changed the password.

[tzeumer]

Great. I changed the user group back too, if you want to try the login on our homepage for some reason.

[campbell-m]

I've had a look at this. It needs some work before it can be merged. The main issues are (a) it's too specific to your site and (b) it needs a SessionPaia class.

If you like I'm happy to make the necessary changes.

[campbell-m]

In fact I think it really needs generic OAuth2 auth and session classes and then the PAIA classes would be subclasses of those. I'm still happy to take a look as I have some OAuth2 implementations that I've been using elsewhere.

[tzeumer]

(a) it's too specific to your site

Oh that's probably the "addons/checkin/ban_check.inc.php " part. Yes I see that makes little sense for others of its own.

Maybe as explanation useful: I currently update a version in parallel (Readme with changes) with your releases and add PAIA, a checkin addon and minor other changes. And it would be great if finally only the addon and theme/tubhh folders differed from the official code.

If you like I'm happy to make the necessary changes.

It would be great. But please only if it is not too much work. And thank you very much for the time you have already invested.

[campbell-m]

One other comment. Is there a reason why you store the display name together with the barcode as the username? I think ideally it should be just the barcode, as the display name can change (eg when someone gets married), meaning that a user can be prevented from accessing their own bookings.

[campbell-m]

It would be great. But please only if it is not too much work. And thank you very much for the time you have already invested.

OK, but it may be a few weeks before I have time to do it. But I think it would be generally useful.

[tzeumer]

Is there a reason why you store the display name together with the barcode as the username?

In the beginning we used it in the navigation bar (but not for the bookings and logins themselves). People look rather for their name than the barcode, so the display name was helpful for the theme. In between we switched to a generic "My reservations & cancellation" in the menu. Now we really never use the real name and the barcode is (except for the search) always hidden in default fields for reservations.
In short: yes, a config option probably always was a bad idea. Edit: A really bad idea.

But I think it would be generally useful.

Thank you!

[campbell-m]

Looking at the PAIA spec I see the following possible values for a patron's status:

• active
• inactive
• inactive because account expired
• inactive because of outstanding fees
• inactive because account expired and outstanding fees

Should a patron whose status is anything but "active" be given MRBS level 0?

[tzeumer]

TL;DR: With very rare exceptions we never deny anyone entry to the library, active membership or not. Therefore it never mattered. But viewed from the system side, it would make sense to block logins for anything but active accounts and give patrons a message like "Your account is blocked, please ... do this or that", I guess.

Slightly longer thought train, only for the interested reader

In our library system expired accounts are deleted after two years unless not renewed by the patron in between. After that a login is impossible because the account just does not exist.

We started using MRBS when Corona started, together with a checkin addon (for contact tracing). Since we have the contact data even for inactive accounts, we allowed all check-ins (made by the checkin addon). People without MRBS booking were kept as "guest" in the log. Everyone else who checked in would keep their MRBS reservation (otherwise deleted some time later). Thus we had a perfect and privacy oriented tracing tool (and also could - and can - release reservations again if people don't check in in a given time frame).
Later I added the banned user option (which we really used only maybe one or two times in four year). This was easier to manage with the MRBS "hack" than with our library system, because I could set a date when the ban would be lifted automatically while in the library system we would have to set some extra external reminder for ourselves. Also, Corona was the only time, when everyone checked in at the entry. Now only people with bookings check in. So it was also the only time we ever could enforce a ban without actually recognizing a banned patron entering the library.

With the end of Corona tracing needs the main purpose for bookings is (again) to make parts of our limited seats available in a convenient way. Personally I still would not mind if someone with too many fees or too many reminders could make a booking. But I guess, many people would see that differently and thus only an active account should be able to make bookings.