AuthProxy native login fails if username begins with a number

Bug #1828456 reported by Jeff Davis on 2019-05-09
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Evergreen
Medium
Unassigned
3.1
Medium
Unassigned
3.2
Medium
Unassigned
3.3
Medium
Unassigned
3.4
Medium
Unassigned
3.5
Medium
Unassigned
3.6
Medium
Unassigned

Bug Description

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. :)

tags: added: authentication authproxy
Revision history for this message
Jeff Davis (jdavis-sitka) wrote :

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

tags: added: pullrequest
Changed in evergreen:
milestone: none → 3.4-beta1
Galen Charlton (gmc) on 2019-09-11
Changed in evergreen:
milestone: 3.4-beta1 → 3.4-beta2
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Jeff Davis (jdavis-sitka) wrote :

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.

Galen Charlton (gmc) on 2019-10-02
Changed in evergreen:
milestone: 3.4-beta2 → 3.4.1
Changed in evergreen:
milestone: 3.4.1 → 3.4.2
Changed in evergreen:
milestone: 3.4.2 → 3.4.3
Changed in evergreen:
milestone: 3.4.3 → 3.5-alpha
Changed in evergreen:
milestone: 3.5-beta → 3.5.0
Changed in evergreen:
milestone: 3.5.0 → 3.5.1
Changed in evergreen:
milestone: 3.5.1 → 3.5.2
Changed in evergreen:
milestone: 3.5.2 → 3.6.1
Changed in evergreen:
milestone: 3.6.1 → 3.6.2
Changed in evergreen:
milestone: 3.6.2 → 3.7-beta
Revision history for this message
Kyle Huckins (khuckins) wrote :

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.

Revision history for this message
Jeff Davis (jdavis-sitka) wrote :

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.

Revision history for this message
Jason Boyer (jboyer) wrote :

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.

Changed in evergreen:
milestone: 3.7-beta → 3.7-beta2
Changed in evergreen:
milestone: 3.7-rc → 3.7.1
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers