AuthProxy native login fails if username begins with a number

[Jeff Davis]

EG 3.1+

When AuthProxy is enabled, native login will always fail if your username begins with a number (even if you use your barcode to login), unless your username and barcode are the same.

AuthProxy always uses the username for login purposes -- if you provide a barcode, it will look up the associated username. But for native login it uses open-ils.auth.authenticate.init, which redundantly and incorrectly uses a hard-coded barcode pattern of '^\d' to check whether the identifier it is given is a username or a barcode (see bug 1827296). If your username happens to be the same as your barcode, this won't be a problem. But if your barcode is 123456 and your username is 2legit2quit, native login will always fail.

The easiest solution is for AuthProxy to abandon the old init+complete method and use open-ils.auth.login for native login instead. It will treat the username as a username instead of applying a bad barcode pattern, thus allowing patrons whose username begins with a number to login. Plus open-ils.auth.login is cleaner and probably more future-proof, so we should use it anyway. :)

[Jeff Davis (jdavis-sitka)]

Working branch user/jeffdavis/lp1828456-authproxy-native-login-method makes AuthProxy use open-ils.auth.login for native login:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=727bccb9

[Jeff Davis (jdavis-sitka)]

Note that there is a bug in open-ils.auth.login for some password values (bug 1830642); that bug has a pullrequest but a concern was raised about backporting the fix to maintenance releases. Probably both bugfixes should be released together.

[Kyle Huckins (khuckins)]

Just to confirm - This involves being able to log in to the staff client under said conditions, correct? If so, I'm seeing no issues with the supplied branch on the festivus feedback fest server when trying to log in as the noted account set up to test this bug.

I'm unable to log in with the user on the OPAC using the username, but not sure if that's expected behavior or not. If it's expected that the user wouldn't be able to log into the opac with said username, then I can sign off on this one. Just want to confirm first.

[Jeff Davis (jdavis-sitka)]

With this branch, login ought to work for both the staff client and the OPAC, assuming (1) auth_proxy is enabled, (2) you have a working authentication proxy that includes your test user's credentials, and (3) your authenticator config in opensrf.xml includes both "staff" and "opac" (or "all") under login_types.

The fact that login is not working in the OPAC could mean that you are falling back to native authentication, in which case login fails (for usernames starting with a number) due to bug 1827296. It's normal to fallback to native auth when your user credentials aren't valid for your authentication proxy, i.e. if your test user doesn't exist on your LDAP server.

[Jason Boyer (jboyer)]

To confirm: festivus does have auth_proxy enabled but is only using native auth (since native auth is what this branch is intended to fix). Jeff is right that bug 1827296 will still be an issue in the opac, which should probably also drop the init / complete login method and use open-ils.auth.login.