TPAC: Enable LDAP authentication

[Dan Scott]

The open-ils.auth_proxy support that was added in 2.2 enabled hooks for LDAP authentication (and other backends) in JSPAC, but we need to extend that support to TPAC.

[Dan Wells (dbw2)]

Here is a branch to address this:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/dbwells/lp1013672_tpac_auth_proxy

[Dan Scott (denials)]

I've signed off on your commit, Dan, and pushed an additional commit onto user/dbs/ldap_tpac. Thanks for this, it's key functionality for us!

There were a couple of problems I had in testing it, but the main one was that "org" was always coming back as "1" (and thus evading any of the non-native authenticators associated with orgs 3 & 4) because the "loc" param wasn't being submitted as part of the form.

In addition, I don't know whether "loc" is really the right option anymore; we use "locg" for location groups, and "loc" and "physical_loc" and "plib" params for various combinations of determining the user's search library. Also, it's a bit weird to conflate search location with logic associated with the user login methods.

So, although I added some logic to login/form.tt2 to populate $org_unit if there is a CGI param for locg or loc (which there isn't by default; it gets wiped when you click "Login"), the best bet might be to set a variable in config.tt2 and use that, then document it for users such that when they create new skins, they can set the corresponding value in one configuration file, rather than having to override the rather lengthy login/form.tt2.

Anyhoo, see user/dbs/ldap_tpac in the working repo.

[Dan Wells (dbw2)]

Dan, thanks for working through this and figuring out all the factors at play here. You are definitely correct in that we don't want search location to influence login methods, so that alone is a bug in the login method in master. The JSPAC used "ol" (ORIGLOC) for the login org_unit value, and I think the only reasonably "correct" value we can reference here would be its correlate, "physical_location". In addition to being more logically sound, it also has the benefit of being cookie-based, so no hidden form values are needed.

I have pulled, generally mangled, and force pushed to the original branch all the relevant changes. I left it as two commits to highlight the differences in purpose:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/dbwells/lp1013672_tpac_auth_proxy

collab/dbwells/lp1013672_tpac_auth_proxy

Thanks again, Dan!

[Dan Wells (dbw2)]

Also, the new branch is rebased to current master.

[Dan Scott (denials)]

Many thanks, Dan! I have pushed this to master.

We should put together a quick Release Notes entry that mentions the relationship between physical_loc and org associations for the non-native authenticators, if not a bit of a cookbook entry :)